 Welcome to this video app series. I'm your host Min Koo Yeo, an applications engineer for ST's wireless microcontrollers. This video is an overview of the heart rate monitoring example when using the STM32WB series. Before we start, please check you have all the prerequisites installed. You can check video number three for tool installations. From video number nine, you've watched how to update the BLD stack and the fuzz, which stands for firmware upgrade services. Please make sure both the BLD stack and the fuzz are updated properly. If not, the BLD examples won't work as expected. So if you have all of these prepared, we are ready to go. This video is a warm-up session, so we are going to observe the overall flow. Let's take a look at the heart rate example, which looks like this. Open the BLD sensor app. Click the magnifying glass icon to scan nearby BLD devices. I'm powering the nuclear board using a portable battery. After the board is powered, the mobile app can detect this BLD device. Click the device to request a connection. After it is connected, the BLD device updates the heart rate value every second. When using the wireless dual-core STM32WB series, CP1 runs the user's firmware applications, such as a heart rate monitoring example. CP2 is a network processor that processes network stacks, like BLE. This typical BLE example shows that there are two clear roles between these devices. A scanning device and an advertising device. These devices are known as a central device and a peripheral device. Since we're going to use the STM32WB board, our perspective is focused on the peripheral. The peripheral advertises BLD packets so that the central device can scan the peripheral device. While advertising, the peripheral receives connection requests from the central devices. After the connection is established, the peripheral is ready to send and notify various data to the connected central device. Let's have a simple exercise by copying the example project. After copying it, our goal is to change some configurations, build and debug the project. Make sure you have the aforementioned prerequisites. To copy the files, navigate to the default STM32Q directory. I'm going to create a copy so that we can freely change the examples later on. Please note, this copy should be placed as close to the base folder of your hard drive as possible. In my case, I'm going to create a new file called demo in my C drive like this. There are various heart rate examples like an example using the free RTOS. In this video, we're going to use the basic heart rate example. Now navigate to the directory shown in the screen and you'll see various files in here. Choose a file depending on your preferred IDE tool. In this video, I'll use the STM32Q IDE, so I'll choose this file called SW4STM32. So, let's compile this example project. This file contains the system workbench toolchain. Now this is compatible with the STM32Q IDE. Open the .project file to import this project. Click OK and finish. Nice, this is converted properly. Let's continue. Now highlight the project by clicking it. You'll notice the hammer icon is now enabled. By clicking this hammer icon, you can compile and build your project. After this step, you need to set the debug configuration. Click the drop down arrow from the debug icon. Click debug as and select STM32 application menu. There are mainly two things to check. First, check the CE application and the project name tab, whether it is showing the B of the heart rate properly. Second, from the debugger tab, make sure the interface is SWD mode. After connecting your nuclear board to the computer, click OK. Now you can start debugging. The STM32WBQ package provides various configuration options and the user can edit this by changing the values in the app config file. This is similar to turning on or off a switch. The user can set the preprocessor to 0 or 1 to enable or disable certain features. For now, let's enable the debugger and read the traces by setting these preprocessors to 1. Also, let's use the full trace option to see the message, the API name, the file name, and the line numbers. With this setting, you can see certain messages printed from Terra Term terminal telling you what is going on. The upcoming videos will explain other preprocessors as well. Let me quickly rebuild the project after editing this configuration. Click down the drop-down arrow from the STM32LPMIF.C file and use the open declaration option to open the app configuration header file. Change the preprocessors and rebuild this project and press the debugging icon. Now let's place a breakpoint in the app entry.c file. This event receive function is called when CPU2 is ready to receive a request to enable a wireless stack. If you see the breakpoint being triggered in this function, the BLD stack is running properly. From line 142, right-click the app entry in it function and click open declaration. You have now switched to app entry.c file. Scroll down near line 196 and you'll see the user event receive function. Move the mouse cursor near the line numbers and right-click and select toggle breakpoint. Click the resume icon to run the debugger. On the debugging panel, it shows that this breakpoint was toggled and this means the BLD stack is running properly. Let's take a look at what Terra Term is showing. Check the comport and the settings from Terra Term. Press the reset button and you'll see the traces. The app debug message which is similar to the printup function prints the messages depending on the preprocessor setting. So when working with ST's BLD examples, the code will initialize various things such as clock speeds, the RTC, sequencer, low power mode, timer server, BLD services and characteristics. When BLD services and characteristics are initialized successfully, the trace messages will appear. After the initialization is done, the device is configured as a fast advertising mode. In the firmware application, the user can check the device connection status variable. This variable shows various states such as idle meaning no BLD activities, fast advertising, low power advertising and more. This enumerates from zero so state zero means idle and state one means fast advertising and so on. There's one timer server configured to wake up in 60 seconds after the fast advertising starts so the fast advertising modes last for 60 seconds and the firmware application will change to low power advertising mode. Now the advertising interval has changed to one second meaning the peripheral is less frequently advertising than before, lowering the power consumption. This was a brief overview to get started with the STM32WB BLD examples. So what are the jargons I'm seeing such as advertising or characteristics? Click to learn more about ST's video app series. I'm looking forward to seeing you again. Thank you!