STM32WB5x battery-powered BLE device - missing low power APIs?

[SVogl.1]

Dear all,

we are trying to build a simple battery-powered BLE device. It should basically measure at intervals and advertise results only (minus the occasional update connection). With limited power resources we would expect to shut down both cores and have a 10 uA-ish power consumption, set aside the occasional advertisement- and rx-timeslots.

That said, we have code running on the Nucleo-WB and a custom baord with the STM32WBMMG but with surprisingly high power consumption*. To eliminate our code as a cause, running the BLE_Beacon sample consumes around 7mA average after disabling the blue LED.

Then, I enabled the  CFG_LPM_SUPPORTED in app_conf.h resulting in 2.4 mA - right direction, but still a factor away from where things should be.

I then had a look at the aci_* API to interact with the BLE framework on the second core but did not find any (official) way to set CPU2 to sleep resp. wake it at advertisement interval times. As far as I understand the forum entries, the LL_CPU2 calls do control the second CPU but this will trigger unknown behavior in the BLE stack.

Is there a canocial way to tell CPU2 to: advertise, listen(x ms), sleep(y ms), repeat ?

Simon

 

* power measurement with the X-NUCLEO-LPM01A  powering the Nucleo WB55 via JP3 at 3.3V

[Remy ISSALYS]

Hello,

There is nothing to do to control the CPU2 low-power mode, the wireless firmware sets on its own the best low-power mode configuration of CPU2 as soon as CPU2 is started. In addition on WB55, STOP2 is the deepest low power mode supported when RF is active. On your board, maybe there is some peripheral or pulls up that generate this extra consumption. 

Best Regards

[SVogl.1]

Dear Remy,

thank you for your advice; I was wary about our hardware as well, so I am using a plain P-NUCLEO-WB55 for
testing, no external hardware attached. Same goes for software - to have a known common ground, I started off
with an unmodified BLE_Beacon example.

Meanwhile I made some progress by

• setting CFG_LPM_SUPPORTED to 1
• disabling all debug related defines like CFG_DEBUGGER_SUPPORTED, CFG_DEBUG_APP_TRACE, CFG_DEBUG_BLE_TRACE, CFG_DEBUG_TRACE_LIGHT / ..._FULL
• enforcing STOP2 mode by calling PWR_EnterStopMode() in UTIL_SEQ_Idle
• tried to turn off debug explicitely with CLEAR_BIT(DBGMCU->CR, DBGMCU_CR_DBG_STOP) in EnterStopMode (no change)

With that, I am at an average power consumption of 580uA at 3v3 which is better, but still not where I want it to be

I also tried to unset CFG_DEBUG_TRACE_UART which made power consumption go up to ~1mA

I am suspecting that there might still be a pin configured and will look  further in that direction - what would you suggest?
Simon

P.S. this is w/ STMCubeIDE 1.13.0, latest FW version (1.17.0 IIRC).Besides, importing examples into StmCubeIDE is half-useful as the code generator writes to wrong subdirectories, breaking the project.

[Remy ISSALYS]

Hello,

In STM32CubeWB package, BLE_HeartRate example is our reference for low power, this application is by default configured to support low power mode ( No traces - No debugger ). Started from BLE_Beacon example, you should have the following configuration in app_conf.h file to reach the lowest power consumption:

#define CFG_LPM_SUPPORTED 1
#define CFG_DEBUGGER_SUPPORTED 0
#define CFG_DEBUG_BLE_TRACE 0
#define CFG_DEBUG_APP_TRACE 0
#define CFG_LED_SUPPORTED 0

In addition, you have to unplug jumpers present on JP5 in order to reach best current measurements.

With this configuration, you should reach around 3.3 uA at 3v3.

Best Regards

[SVogl.1]

Dear Remy,
thank you for the hints - I did a cross-check, I had these defines already in place. I removed all jumpers from JP5 as indicated, now I am at an (100s) average of around 50-70uA, with live current going down to roughly 3uA as expected.
So the rest is up to software as the refman indicates the values stated at an advertisement interval of 10s

Thanks for your help

Simon