Power modes support for CPU2 for STM32WB5x microcontrollers

[r2r0]

Is your feature request related to a problem? Please describe. It will be very useful if CPU2 in STM32WB5x will also use low power modes ()STOP0, STOP1, STOP2) in similar fashion as it is implemented for CPU1.

Describe the solution you'd like Low power modes for CPU2 can be entered at the same time like for CPU1 (i.e. as in function pm_power_state_set in soc/arm/st_stm32/stm32wb/power.c) Actual low power mode for CPU1 may be chosen depending on current BLE activity.

Describe alternatives you've considered I haven't found good alternative till now.

Additional context Even if BLE support is disabled in Zephyr (at compile time) then power consumption in STOP2 mode is 2 magnitudes higher than expected (over 110 uA). This feature can be also useful for STM32WL55 family.

[erwango]

Even if BLE support is disabled in Zephyr (at compile time) then power consumption in STOP2 mode is 2 magnitudes higher than expected (over 110 uA).

@r2r0 Can you provide more information on this part (expected target, test condition, ...) ? Also, please note that implementing power mode support for CPU2 won't have a direct impact on this figure.

[r2r0]

We added a test mode for our application where there is no other activity than very short action at every 250ms and there is enabled standard residency PM policy (as well as LPTIM and tickless kernel). Because of other issues we disabled BLE at Kconfig level. For test purposes we switch most of pins to analog mode before we entering to STOP modes (to minimalize current leaks not important for this tests). In this case we found that during waiting time (between application activities) power consumption varies roughly between 100 and 180 uA which is very different from what we expect (basing on datasheet values). After we added LL_C2_PWR_SetPowerMode(LL_PWR_MODE_STOP2) at line 91 in soc/arm/st_stm32/stm32wb/power.c the power consumption (during waiting period) dropped to range 10-70 uA what looks more in line with datasheet. BTW> we still investigate what causes current consumption variations during sleep time.

[r2r0]

The line 108 in the attached example makes a big difference in power consumption. blinkyPM.zip

[erwango]

@r2r0, thanks for sharing.

Digging a bit more into RM, I've found the following (§6.4): "The system low power mode to enter depends on the allowed mode selected by both CPUs in the LPMS bits of PWR control register 1 (PWR_CR1) and PWR CPU2 control register 1 (PWR_C2CR1). This is also valid when CPU2 is kept in hold by C2BOOT."

So indeed, CPU1 STOP modes entry with CONFIG_BT=n also depend on C2 LPMS (so I guess this is also valid for STOP0/1 mode entry). What could be interesting is to see impact when C2 LPMS is set to SHUTDOWN, to be coherent with C2 state.

Would you mind checking to effect when using the following in function stm32wb_init (soc.c) ?

LL_C2_PWR_SetPowerMode(LL_PWR_MODE_SHUTDOWN);

[erwango]

@r2r0, Please have a check to https://github.com/zephyrproject-rtos/zephyr/pull/38174. It does not intent to close current issue, but at least, I hope it fixes the point you reported.

[r2r0]

Thanks @erwango Yes, indeed adding this line in soc.c allows to enter SHUTDOWN mode when BLE is disabled.

[erwango]

@r2r0 Now that we've closed the no BLE issue, I'd like to come back on the initial request:

It will be very useful if CPU2 in STM32WB5x will also use low power modes ()STOP0, STOP1, STOP2) in similar fashion as it is implemented for CPU1. [...] Low power modes for CPU2 can be entered at the same time like for CPU1

Do you mean that you'd like CPU2 power states to be selected from CPU1 during BLE operations ?

[r2r0]

IMHO implementation should allow to obtain lowest possible power consumption. When there are requested Zephyr PM states which cause lost of context i.e. PM_STATE_SOFT_OFF (mapped to MCU SHUTDOWN mode) then it can be assumed that user consciously wants to stop any application activity and then mode requested from CPU1 should force requested system state (and mode on CPU2). For other low-power modes, CPU1 should only try to switch system (the whole MCU) to requested low-power mode but the end result will depend if CPU2 allows that mode at request time. In case when CPU2 allows to enter low-power mode then it should be able to wake-up system if i.e. radio system needs it (obviously when BLE is configured but not activated then it should not wake-up MCU). It should be possible to configure Zephyr to configure CPU2 to allow entering low-power modes i.e. STOP2 and then CPU1 will use its own policy to request system modes.

[erwango]

@r2r0, back on this topic. So IIUC, there are cases were you see CPU2 is not allowing to enter deepest low power mode, while there is no BLE activity on going. Is that correct ?

[r2r0]

@erwango Exactly. As the begin we start using SHUTDOWN mode and the problem appeared. Maybe SHUTDOWN it is a special case but I assumed that similar problems can be present for other modes and it is why I submit this issue. At the beginning it would be nice to have SLEEP and STOP modes working - I mean if main CPU enters one of such modes then radio CPU should try to follow it. Additionally there is a case when BLE is not in use (i.e. not configured) then it would be really interesting to have functionality where CPU2 is constantly kept in the state allowing to achieve the lowest possible power consumption.

[erwango]

@r2r0 Please note that on V1.12.0 STM32Cube M0 f/w, there's a regression that have the effect on preventing M0 to switch to stop 2 when advertising stops (and similar issues). This regression will be fixed in upcoming v1.13.0

The way M0 should behave in theory is that it's handling its LP modes on its own and try to achieve the lowest possible mode depending on what is expected from it (BLE activity of not). Then, the platform power mode will be the highest requested between M4, M0 (and RF). As a consequence, M4 should do the same and only consider its needs, and achieve the lowest possible state, and not care about M0.

Using V1.11.0 STM32Cube M0 f/w, you'll be able to observe this behavior.

For instance, here is a power consumption snapshot (using V1.11.0 STM32Cube M0 f/w) done when working on #https://github.com/zephyrproject-rtos/zephyr/issues/37882 (unit is uA): Scenario is the following: Board Startup (M0 is put to shutdown mode) M0 startup Advertising start Advertising stop Advertising stop Board shutdown

You can observe that the platform is reaching stop2 mode when possible between advertising peaks. Also, when advertising stops, platform remains in stop2.

Can you confirm the behavior described and shown in this picture would satisfy your request ?

[r2r0]

@erwango I am sorry for late answer but we struggled to switch to the newest Zephyr (#39752 is weird). After that I can confirm that with enabled BT and PM residency policy we can get reasonable power consumption.

[erwango]

@r2r0 Thanks for your feedback. Can you elaborate on "#39752 is weird" ?

[r2r0]

Two weeks ago we started switching to the newest Zephyr but we found that something causes hard faults. It was weird because after adding a few lines of code in totally unrelated places (sometimes) make fault to disappear. Also on one our second device (only small difference on DT pinout) this problem was not visible, so we started to find problems in our application code and after few days without any effect we started checking changes in Zephyr drivers. After more than week of investigations we found cause of the problem and next day by coincidence the #39752 appeared on github.

[erwango]

Thanks for these details. We'll take care it is merged and backported to V2.7.0 branch.

[erwango]

@r2r0 I'm closing this issue since https://github.com/zephyrproject-rtos/zephyr/pull/38980 has been merged and current behavior is confirmed to be correct.