STM2WBA65RI Low-Power Mode (STOP2)

[JPortilha]

Hello,

I am currently using the STM32WBA65RI development kit and exploring its low-power modes. I have run the STOP2 mode example and, according to the datasheet, the current consumption in this mode should be around 5 µA.

However, I am measuring the current using an external power supply with measurement capabilities (SMU), powering the board through JP2 pin 1 as specified in the user manual. In this setup, I observe a current consumption of approximately 300 µA while in sleep. Could you help me understand why there is such a large discrepancy? What steps are required to achieve the ~5 µA consumption stated in the datasheet?

I also have a few additional questions regarding this mode. In the example, the function
HAL_PWR_EnterSTOPMode(PWR_MAINREGULATOR_ON, PWR_STOPENTRY_WFI) is used, but it is not clear where STOP2 mode is explicitly selected. According to the official documentation, there are also STOP0 and STOP1 modes, which adds to my confusion.

Additionally, I have seen examples where the RTC is used as a wake-up source, and the HAL SysTick is suspended to prevent unintended wake-ups. Is this step necessary?

HAL_RTCEx_SetWakeUpTimer_IT(&hrtc, 0x4E20, RTC_WAKEUPCLOCK_RTCCLK_DIV16);

/* Suspend the SysTick interrupt before entering STOP mode to prevent wake-up */
HAL_SuspendTick();

Finally, I am considering integrating ThreadX. Is it possible to achieve the same low-power behavior when using an RTOS? What changes would be required to maintain similar functionality? I have also come across discussions suggesting that low-power modes with an RTOS can cause issues such as tick desynchronization. What is the expected current consumption when using an RTOS in this context?

Best regards.

[Khaled_DHIF]

Hello @JPortilha ,

The STOP mode is selected through the Regulator parameter passed to HAL_PWR_EnterSTOPMode(). According to the HAL API description, this parameter can be one of the following values:

- PWR_LOWPOWERMODE_STOP0: Stop 0 mode, main regulator ON
- PWR_LOWPOWERMODE_STOP1: Stop 1 mode, low power regulator ON

and, on devices where supported, additional modes such as STOP2 or STOP3 may also be available.

So, the selected STOP mode depends on the argument provided in the function call. The STOPEntry parameter does not select STOP0/STOP1/STOP2; it only specifies whether the mode is entered using WFI or WFE.

 

 

Regarding the measured current, a value around 300 µA does not necessarily mean that STOP mode is not being entered correctly. The very low values shown in the datasheet are usually obtained in MCU-only conditions with a tightly controlled hardware setup. On a development board, the measured current often includes additional consumption from the debugger interface, LEDs, pull-ups, voltage regulators, external components, GPIO configuration, active peripherals, and clock sources. Because of that, the current measured on a board can be significantly higher than the datasheet figure even if the MCU is correctly entering STOP mode. For more information refer to this article: Tips for using STM32 low-power modes - STMicroelectronics Community

 

 

For SysTick, it is generally recommended to suspend it before entering STOP mode if the goal is to minimize consumption. Otherwise, the periodic SysTick interrupt can wake the CPU regularly and prevent the system from remaining in STOP long enough to reach the expected low current. If RTC wake-up is used, the common sequence is to configure the RTC as wake-up source, clear the relevant wake-up flags, suspend SysTick, enter STOP mode, then restore the system clock and resume the tick after wake-up.

Using an RTOS such as ThreadX together with low-power modes is possible, but it requires proper low-power integration, typically through a tickless mechanism. If the RTOS tick continues to run periodically, the CPU will keep waking up and the average current will remain much higher than expected.

 

 

In summary, the main points are:
- The STOP mode is determined by the Regulator argument passed to HAL_PWR_EnterSTOPMode().
-The measured current is highly dependent on the external hardware environment and board configuration, so a current around 300 µA on a development board can be affected by the overall setup and not only by the MCU low-power mode itself.

- SysTick should be suspended if periodic wake-ups are not desired.
- RTC wake-up is valid, but it adds some consumption and requires the proper suspend/resume sequence.
- With ThreadX, low power should be managed through the RTOS low-power mechanism.

Kind regards, 

DHIF Khaled

[JPortilha]

Hello, and sorry for the late reply.

I have been exploring your example “BLE_HeartRateThreadX”, which provides a good base for what I am trying to achieve. From my analysis, the example initially runs a 60-second fast advertising phase, with intervals of 20–30 ms, which results in higher current consumption. After this period, it transitions to a low-power advertising mode with intervals of 1–2.5 seconds.

From what I understand, low-power management is handled automatically by the RTOS together with the LPM module. The Idle task appears to be responsible for placing the system into low-power mode and setting the Link Layer into deep sleep. The Timer Server API then uses the RTC as a wake-up source whenever the radio needs to transmit a BLE packet. Based on the configuration, it seems the application automatically determines whether there is a sufficient time window to put the MCU into sleep before the next transmission.

Could you please confirm if this understanding is correct?

Using this example, I measured the current consumption following the method described in the first post. According to the datasheet, this method powers only the MCU, meaning that all additional hardware on the development kit (such as LEDs, ST-Link, etc.) is disabled. I configured the low-power mode to the maximum level (level 2, i.e., standby) and disabled debug/logging features to minimize consumption.

 

I have attached a photo of the results. During the fast advertising phase, there are visible current peaks. When the system transitions to low-power advertising, the current drops to around 15 µA, which is very close to the datasheet specification for BLE advertising in standby mode. However, even in this mode I get random peaks, what are they?

Based on this example, I developed my own application following the same principles. However, in my case, I use low-power advertising continuously. Therefore, I expected to observe a relatively constant current around 15 µA, without significant peaks.

However, as shown in the attached images, there are multiple current spikes that I do not fully understand. Could these spikes correspond to BLE packet transmissions? Some of them seem to be separated by 2.5 second what would make sense, but this beahviour is not constant. If so, why does this not happen in the original example?

Any insights would be greatly appreciated.

Best regards.

[JPortilha]

Hello, quick update, I have removed the line that starts the advertise from my code and the mean consumption should be around 7uA. So I'm guessing the spikes are related to the BLE advertise.

Also, I have another question. As I am using ThreadX, this comment appears on the app_conf.h file: "If Standby is enabled we need to disable ThreadX low power Framework, TX_LOW_POWER must not be defined in assembly preprocessor configuration. IDLE task approach is used to manage Standby low power properly." What does this mean? Do I need to disable the ThreadX Low Power support to achieve standby mode with BLE advertise?

When I make debug, inside the ThreadXLowPowerUserEnter function, the code does not go to the 

APP_SYS_BLE_EnterDeepSleep() function, as the UTIL_LPM_GetMaxMode is returning 1, which means Sleep. I only have the STANDBY_MODE active on the app_conf.h, the STOP modes are disabled. Can you help me understand this? My goal was to reach a power consumption of 1uA if possible (which seems to be in Standby mode) according to datasheet.