 Welcome to this presentation on CubeMonitor Power. Today we will demonstrate consumption measurement of typical BLE peripheral application with this software. CubeMonitor Power is designed to operate with STM32 PowerShield, which is a variable voltage power supply that is able to measure current consumption of STM32 WB Nucleo or any other custom design board. We will begin with list of hardware and software prerequisites for the demonstration. We will introduce capabilities and features of STM32 PowerShield and CubeMonitor Power. Then we will take a look on consumption measurement of simple BLE peripheral application on WB Nucleo. At the end I will show you some tips and tricks for the consumption measurement. Here is the list of prerequisites and other useful materials for this session. Please take the time to watch the other videos of this WB Getting Started series. You may also find useful user manual of CubeMonitor Power software tool, the user manual of STM32 PowerShield and also Getting Started with PowerShield firmware. For this session we will require CubeMonitor Power installed on your PC. We will also use CubeProgrammer to load the test firmware onto WB Nucleo. It is assumed the BLE stack is already installed on the device. To connect to the WB Nucleo over BLE we will use STBLE sensor application installed on your Android or iOS phone. If you would like to measure consumption at different BLE setup you may optionally use one of the supported IDEs to modify the BLE hardware example. From the hardware point of view we will need STM32 WB Nucleo board, STM32 PowerShield, two USB micro cables and some jumper wires. PowerShield supply WB and measures the current consumption over time. After we load the test firmware into WB, the power wires will be the only connection to the target. PowerShield communicates with PC over USB virtual comport to transfer the measured data into CubeMonitor Power software tool. Let's have a quick overview of STM32 PowerShield capabilities. STM32 PowerShield can supply the target from 1.8V up to 3.3V. It can sample the current with 1kHz frequency which allows to measure even transient behavior such as low power entry or load switching. The dynamic range starts from 100nm and ends up at 50mA which allows to measure accurately all the low power modes of STM32 product. It has been chosen as an official EEMBC energy monitor for benchmarking. To avoid any issues during the measurement I suggest to upgrade to the latest PowerShield firmware which can be downloaded at ST website. The upgrade procedure is thoroughly described in user manual UM2269. Let's get started by measuring the consumption of BLE hardware example which you have already seen in previous video of this Getting Started series. This demonstration can be split in three parts. First we will flash WBN with the pre-compiled binary of BLE hardware example which can be found in WBQ package. We will supply the nuclear from PowerShield and take a look at consumption in CubeMonitor Power. We take the measurement while the device advertises and also when it's in connection with the phone. Let's begin by connecting STM32 WB nuclear to the PC and launching Q programmer. Let's locate the pre-compiled hardware example in WBQ package and let's flash it into the target. This example has the low power modes enabled by default. For most other BLE examples in the repository the low power modes can be enabled easily by compiler switch. Once we are done we can disconnect the STLINK USB cable and get ready for the next step. Now is the time to connect PowerShield so that it can provide power to the nuclear and the current measurement to the PC. Start by connecting PowerShield to the PC via USB cable. Then connect ground and VDD to the highlighted headers. Also remove all the highlighted jumpers to break the connection between STLINK and STM32 WB. Keeping these jumpers on would result in increased current consumption which is not directly related to the consumption of WB and its application. Before we take the measurement let's have a look on what we expect to see. After powering the board the CM4 and CM0 plus performs initialization of peripherals and BLE stack. The application then goes to fast advertising mode with period of about 100 milliseconds. After one minute the application slows down the advertising period to about 2 seconds. In between the advertising interval the MCU is in stop mode and the consumption is in the range of few microamps. During the advertising event we will see increased consumption in range of milliamps which is caused by the radio and CM0 plus activity. During this whole time the CM4 remains idle in C stop mode and doesn't execute any code. This is because BLE stack doesn't send any events and there are no other wake-up sources configured for the CM4. We will measure the average consumption of slow and fast advertising and then have a look in detail on the consumption profiles of radioactivity. Now WB nuclear is connected to the power shield so we can go into cube monitor power and connect to the COM port which is created by the power shield. On the left side we see the configuration of the acquisition. We can set the sampling rate to the maximum of 100 kHz. We will not put any limit on the acquisition time so we will take it indefinitely. And we will keep the default supply voltage at 3.3 volts. Once I click start acquisition the board will become powered and we see here at the beginning this increased consumption is the initialization of CM4 and CM0 plus. After this the microcontroller goes into stop mode and wakes up only to send the advertising packet which happens roughly about once per 100 ms. If we keep the device running for about one minute you will see that the device prolongs the advertising interval to about two seconds. So let's wait a bit until we see that. So now I stopped the acquisition and I will zoom out to see all the data. We clearly see when the device is in fast advertising mode and when it switches to the slow advertising mode. We can zoom in into one part and show the report, show the average consumption in this time frame. And it's 266 microamps for advertising interval of about 100 ms. If I zoom out again and zoom into the slow advertising mode I will see the average consumption drops very significantly down to about 1780 microamps. Now I would like to do two more things. Let's zoom in into the area when the microcontroller is in stop 2 mode. And we see the consumption is very close to 3 microamps and these peaks you see it's just RF pickup. Let me zoom out again and let's try to zoom on one of the advertising event. So again this is the time when CM0 plus and the radio are active. And you see some periodic pattern which I would like to describe in more detail on the slide. The device advertises scannable and connectable packets on all three advertising channels. After the packet is sent the radio switches to the RX and waits either for scanner request or connect request. The whole advertising event takes less than 4 ms to complete. Now we will take the phone with STBLE sensor application and connect to the Nucleo. The connection interval is imposed by the phone and is typically about 50 ms. Peripheral could negotiate longer connection interval to save power but this is not implemented in this example. We will again see the periodic pattern of Cortex M0 plus and radio activity which handles each connection event. And once per second we should also see Cortex M4 activity which performs the heart rate measurement and updates the BLE characteristic. So now I will start a new acquisition and we see the device is still advertising in the slow mode. And on the phone I will open STBLE sensor application and perform scanning. And I see the heart rate sensor is detected. I will connect to it and immediately you see in the power consumption that the connection has been established and the phone performs service and characteristics discovery. And we also see the heart rate being sent to the smartphone application once per second. So let me stop the acquisition and let's zoom in in couple of seconds. So you see this periodic pattern. Each of these peaks correspond to RF activity to one connection event. And we should see once per second the activity of the Cortex M4 core which relates to updating the heart rate characteristic. And this is in fact the one we are looking for. So now let's try to take another measurement. Just 100 millisecond will be enough. And we see two connection events during this time. And if we zoom in we see a pattern which corresponds to CM0 plus and our radio activity. And it looks a little bit different compared to advertising event. And I would like to describe it on next slide. Each connection event starts with packet from central. Therefore the radio RX goes first. The peripheral responds either with empty packet or with the notification of the heart rate value. The connection event takes about 2 millisecond to complete with zero length packet response. Let's now have a look on some useful tips and tricks. When you make a modification in the code and you want to test the consumption quickly it may be annoying to connect and disconnect all the jumpers that connect ST-Link with STM32WB. In fact you can keep them all provided that the firmware puts the serial wire debug pins PA13 and PA14 into analog state with no internal pull-ups or pull-downs. The exception is the highlighted header which connects voltage level shifter supply to the target VGD. This level shifter allows to flash and debug the application at lower VGD than the ST-Link's 3.3 volts. But it also draws constantly about 300 microamps which offsets all the measurements we are doing. To be able to both flash the WB easily and measure the consumption accurately we need to supply the voltage level shifter from a different source than PowerShield's VGD. Luckily PowerShield provides a buffered copy of VGD on the left-mode header which we can use just for that. When you connect the ground and VGD from PowerShield to the target always make sure that wires are wrapped around each other to minimize RF pickup. If you don't do that you might see a very apparent noise especially when you measure ST-2 mode consumption. I hope you enjoyed this presentation and that you will be able to utilize some of that in your development process. Thank you.