2023-07-17 06:03 AM
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
Solved! Go to Solution.
2023-07-20 08:33 AM
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
2023-07-19 03:07 AM
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
2023-07-20 02:37 AM
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
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.
2023-07-20 08:33 AM
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
2023-07-21 12:32 AM
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
2023-07-31 07:32 PM
After this change, the ST-Link cannot find the board anymore.
I tried one more deivce but still it becomes not accessable.
How can I restore the board?
2024-04-17 04:57 AM
Did you got this error?