Power Consumption Help with STM32wb55

[od805]

Hello - 

I have a custom pcb using the stm32wb55 and I have spending time optimizing the power consumption. My primary intentions with this PCB is to sample data around 1 Hz and send this data to html server app using BLE. I'm using the BLE_Sensor example as the basis of my current firmware. Seems like BLE_Sensor also includes some motion_server firmware that may be adding to the power consumption but I'm not sure. 

Everything I have tried so far (I'll include links to what I have tried) brings my current consumption down to 74 mA. From what I am reading and observed in guides, that is WAY TOO HIGH!!!

I am trying to use a 3.7 V 110 mAh coin cell to operate the system for as long as possible, but right now it would be for a little over an hour. 

I have tried setting the system clock to MHz, enable HAL_PWR_Ex_EnableLowPowerRunMode(), setting all unused pins as analog, but there is clearly something that is holding me back. from achieving minimal current consumption. PCC suggests that using Lowerpower run mode should average out to 32.17 uA of current consumption but I'm nowhere near that now. 

Could really use some sage advice here. Thanks!

Resources I've looked at:

https://community.st.com/t5/stm32-mcus/how-to-minimize-the-power-consumption-in-low-power-mode-an/ta-p/49801

https://www.st.com/resource/en/application_note/an5071-stm32wb-series-microcontrollers-ultralowpower-features-overview-stmicroelectronics.pdf

https://wiki.st.com/stm32mcu/wiki/Getting_started_with_PWR

https://www.st.com/resource/en/user_manual/um2442-description-of-stm32wb-hal-and-lowlayer-drivers-stmicroelectronics.pdf

Snippets of my current important firmware

[Remy ISSALYS]

Hello,

On STM32WB55, STOP2 is the deepest low power mode supported when RF is active. You can start from BLE_HeartRate example which is by default configured to reach stop2 low power mode (3 uA). 

Best Regards

[od805]

thanks for this. 

The main error I am getting is with the NUCLEOWB55Port.c file (please see attached). In BLE_Sensor the hierchary opens the stm32wbxx_hal_spi.c file but in this case it opens the .h file and give this error I can't get past. Please help.

BLE_Sensor and BLE_Heartrate seem to have pretty different firmwares in the sense of no p2p being present in the BLE_Heartrate firmware. 

Important note: I am currently using the BLE_Heartrate example for the WB55 Nucleo (stm32wb55RGV6). I see that there is an example for the discovery kit (which is what we have, stm32wb5MMGH6TR) and when I compile the disco. kit the current consumption is still enormously high relative to the nucleo example? 

Why is this??? What is the driving factor in the discovery kit firmware (Heartrate and BLE_Sensor) that's enabling such high current consumption and how to mitigate?? (lcd, motion detect, led, etc.). 

[Remy ISSALYS]

Hello,

Do you perform some modification in BLE_Sensor example? Which IDE are you using? 

BLE_Heartrate example embeds HeartRate service/characteristics and BLE_Sensor example embeds P2P and MOTENV services/characteristics.

In BLE_Heartrate example for the STM32WB5MM-DK, low power mode is disable, in addition some peripherals and debug trace are enable. That's why the current consumption of this example is greater than BLE_Heartrate example for the WB55 Nucleo.

Best Regards

[od805]

I am using STM32IDE 1.13.0.

In BLE_Sensor I modify the p2p server app and p2p .c files along with app_entry hw_timeserver and main.c. 

After several days of trial and error I was able to get it to work. I basically fused the necessary BLE_Sensor files (p2p being the most important) with BLE_Heartrate to significantly reduce the power consumption from 150 mA to 80 mA (connected to Debugger) and 80 mA to 10 mA (without debugger and just custom pcb).

It must be able to be further optimized. The lower mode enable and debug trace disable changes didn't appear to do much but I'll try again. 

Any other advice on how to keep reducing the power consumption would be greatly appreciated. I have made significant strides so far. 

THanks!