STM32WB55 fails to enter standby sometimes when BLE stack has run

[NSAUG.1]

Hello,

On a STM32WB55REV, I'm having problems with going to standby.

These problems are intermittent (1 in 30 cycles maybe, sometimes 3 in a row, sometimes none for a hundred of cycles...).

I only started seeing them after I enabled BLE in my application (so before that I did not see them for the last year of development).

I'm using the stack BLE light v1.14.0, FUS is 1.2.0.

STM32_WPAN code is from FW 1.14.0, and started its life as the HRS_FreeRTOS example. The details of my target (no LSE, pin allocation) make running the vanilla example code a chore so I don't really have a "bare minimum" application I can refer to that would run on my target.

I tested my services on the Nucleo extensively though without any problem, and the BLE functionality of my device does not show any problems nor unexpected behavior.

The problem, from a brid's eye view, is that the device sometimes does not enter Standby properly after the BLE stack has run.

No link with what has happened during runtime that I can see (it my only advertise, or connect once, or connect/disconnect multiple times without effect on the bug appearing).

- LL_C2_PWR_SetPowerMode(LL_PWR_MODE_SHUTDOWN) is done before I start CPU2 with the example's "HW_IPCC_Enable()";

When I stop the BLE part of my application (code run only if BLE has been successfully started), I do:

- LL_PWR_DisableBootC2() (because I do not want it to resatart after standby)

- hci_reset() and check the status (always BLE_STATUS_SUCCESS);

When I go to standby, here is the code used. Some of it is maybe cargo-cult code that results from the numerous attempts to locate the problem...

 // disable all interrupts

 for( int i = 0; i<62; i++ ){ // IRQn_Type in stm32wb55xx.h shows the range

  HAL_NVIC_DisableIRQ((IRQn_Type)i);

 }

 // SRAM2a retention needs 2 things: an Option byte set to avoid clearing the RAM on reset,

 // and a flag to force the regulator to power the SRAM while in Standby mode.

 HAL_PWREx_EnableSRAMRetention();

 // Disable all used wakeup sources

 LL_PWR_DisableWakeUpPin(BUTTON_IN_FLAG);

 LL_PWR_DisableWakeUpPin(VBUS_WKUP_FLAG);

 // Clear all wake up Flag

 LL_PWR_ClearFlag_WU();

 // Set wakeup pin polarity

 BUTTON_IN_SET_WAKEUP_POLARITY();

 VBUS_WKUP_SET_WAKEUP_POLARITY();

 // Enable wakeup pin

 LL_PWR_EnableWakeUpPin(BUTTON_IN_FLAG);

 LL_PWR_EnableWakeUpPin(VBUS_WKUP_FLAG);

 // As default button state is high level, need to clear all wake up Flag again

 LL_PWR_ClearFlag_WU();

 // Somhow the internal wakeup line seems to prevent us from entering low power sometime.

 // The problem with this is that the User Manual is basically silent on what it is...

 HAL_PWREx_DisableInternalWakeUpLine();

 HAL_PWR_EnterSTANDBYMode();

Looking at the SFRs by setting a breakpoint after HAL_PWR_EnterSTANDBYMode(), there are no wakeup flags WUFx nor WUFI (anymore), no interrupts enabled (some are pending).

The low power modes of C1 and C2 are as expected (C2 LPMS = 0x4 and C1 LPMS = 0x3).

I just can't see any reason why it would not go to standby... Any idea ?

[NSAUG.1]

Actually I think I just solved it... Rubber duck debugging is the best :)

I had a flash and used what is for me a revolution in debugging : the "Registers - BETA" tab of STM32CubeProgrammer.

Save to file => All peripherals, once with the device stopped at HAL_PWR_EnterSTANDBYMode() in a mode that had started the BLE stack, once after a run that did not start the stack.

Diff on the text files, and the result is in: the RTC wakeup flag (WUTF) is set. I had not been looking in the right place, since all the other ones seem to be in PWR.

It seems that something is not properly cleaned-up relative to the HW_TimerServer, which is where this wakeup flag is set. I really dislike having library code that plays with my hardware without a clean way to de-init it... >_<

Maybe think about creating void HW_TS_DeInit()?

[NSAUG.1]

And (Ihope) to end that post, since the fix to the previously stated cause of the problem is NOT that obvious: https://community.st.com/s/question/0D53W00000NY28FSAT/clearing-the-rtc-wutf-saving-your-sanity-by-sharing-my-hard-lesson-learned-

Why on earth the low level libraries would not implement the low level flag clearing in a way that actually... really clears the flag ???

[Piranha]

Also read and implement this:

https://community.st.com/s/question/0D53W00001bnh8dSAA/how-to-enter-standby-or-shutdown-mode-on-stm32

> Why on earth the low level libraries would not implement the low level flag clearing in a way that actually... really clears the flag ???

Because the respective team is incompetent.

[NSAUG.1]

That would have been a godsend had I found this 3 weeks ago,​ now it's only awesome :)

Thanks!​

[Remy ISSALYS]

Hello,

On STM32WB55, according to the application note AN5289, standby mode isn't supported when RF is active:

STOP2 is the deepest low power mode supported when RF is active. When the user application has to enter Standby mode, it must first stop all RF activities, and fully re-initialize CPU2 when coming out of Standby mode. The user application may use the full non secure SRAM2a to store its own content (that needs to be retained in Standby mode).

Best Regards

[NSAUG.1]

As far as i can tell, I do stop all RF activity, as stated in my initial post.

​

Is there somewhere ​an exhaustive description of how that is supposed to be done? I could not find any...