How to achieve low power Bluetooth advertising with STM32WB

[ChrisLB]

I'm having issues getting the low power sleep to work with Bluetooth enabled on the STM32WB

Is there any guide or app note on steps needed to achieve lowest power level BLE advertising?

Basically no matter what I do - if I enable bluetooth advertising (code extracted from the iBeacon cubemx example) and enter stop2 mode, the stm32 takes about 5.5mA

If I comment out the call to aci_gap_set_discoverable(...) and then enter STOP2 mode, the board goes to ~50uA (most of that is the other hardware we have on this board)

So far, I have:

• confirmed the main core is indeed going to sleep between bluetooth events (measuring the sleep time = advertising interval, also it's easy to see with the debugger)
• tried "forcing" sleep with LL_C2_PWR_SetPowerMode(LL_PWR_MODE_STOP2) (my understanding is that I should not need to do this)
• changing various #defines relating to power, dbg and sleep in the ble header files

I think I might be missing something obvious... Is there any way of seeing why the second core isn't going to sleep? My best guess is that it's a configuration thing but I'm at a loss with what else to try.

Perhaps I need to be using standby mode to force the m0 off between advertising events?

Any help would be greatly appreciated!

Thanks

[Mathieu Wernsen]

Hi Chris,

Thanks for the quick response! Very understandable you forgot about the specifics of the final solution, but I can definitely work with your suggestions.

• I also noticed the issues with the debugger connected and I've adopted the same workflow of flashing, disconnecting debugger + power cycling, before measuring power consumption.
• Interesting fact. I will check this one out.
• I'm making use of FreeRtos for this project. I was hoping the implementation provided by STM in their code generation would result in reliable task handling of the BLE stack, but I will verify this just to be sure.
• Could you clarify this a bit? In my understanding the C2 manages it's own power state, so how could I send a powerdown command to C2? I was kind of expecting the aci_hal_stack_reset to fully shutdown C2.

I guess I just have to spend a few more hours/days fiddling around with settings, hoping to find the solution to this bug, to then hopefully never look back as well 🙂

[ChrisLB]

you might need to dig into the source code to see what stack reset does. I used the low level LL libs

LL_C2_PWR_SetPowerMode(LL_PWR_MODE_SHUTDOWN);

good luck! I hope for your sake that is is a few hours/days, not weeks like me!

[ChrisLB]

btw I've just rechecked our firmware.. no sign of the ADC thing (probably because we stopped using the ADC), so perhaps that was a red herring? All I know was that at the time, even with readings disabled in sleep, I had to kill the peripheral clock to signal to get it working on low power..

[Mathieu Wernsen]

After some further investigation I found out that for me not the ADC clock settings were the issue, but the RNG Clock setting was the cause of the CPU2 not going into Deep Sleep mode (even after a reset of the BLE stack). Switching from the LSE to the HSI48 solved my issues 🙂

[ChrisLB]

Ah nice!! Glad you got it sorted. That actually does sound familiar, I remember moving something to an internal clock also. Probably too much to ask but maybe ST will document this "feature" one day

[Mathieu Wernsen]

Or maybe provide an explanation so we at least understand what is happening inside this "Black-box" called CPU2.

[ASett.2]

To anyone else having an issue similar to this, I'd like to share our recent WB55 BLE advertising sleep debugging experience.

TL;DR: We changed from using hci_reset() to aci_hal_stack_reset() and it solved our power consumption problem.

We were having nearly the exact same current consumption issue when using aci_gap_set_discoverable(). Our WB55 would enter sleep mode correctly, and the M0 core would continue to advertise correctly with the expected level of power consumption, but only for a short time. Anywhere from 15 minutes to ~hours later, we would suddenly see a ~5mA current consumption increase, which would remain for hours, and sometimes resolve itself. We setup a weekend power monitoring test and saw the device enter and leave this high power state, multiple times, for hours at a time.

We tried all the suggestions in this thread and were still having the issue. After seeing references to the aci_hal_stack_reset() call here, we noticed in AN5270 it says: "This command is equivalent to HCI_RESET, but ensures that Sleep mode is entered immediately after its completion.". We had originally ruled this out as our device WOULD enter low power mode correctly at first (when using hci_reset), but the high power consumption would only occur sometime later after running.

We were desparete to try anything so we replaced our call to hci_reset() with aci_hal_stack_reset() in our init routine, ran it through our power consumption tests, and we have been running in low power mode ever since. I'm still not quite sure why hci_reset() would start out having the M0 core go into low power mode only for it to leave low power mode later, but if the functionality is really equivilant as AN5270 says, I see no reason to not use aci_hal_stack_reset() in place of hci_reset() as a general rule.