[BLE] STM32WB55 advertising DeepSleep Bug

[mayrhomar]

Description of defect

When an advertising packet is sent, the microcontroller sometimes does not return to DeepSleep mode. Only if another event occurs (e.g. LPTICKER -> "target.lpticker_lptim": 1) it will return to DeepSleep afterwards. This becomes problematic if the RTC is selected as LowPower Ticker ("target.lpticker_lptim": 0). The Mbed CPU statistics does not recognize that the controller is not in DeepSleep mode.

Power measurement BLE Advertising with:
"target.lpticker_lptim": 0, "target.lpticker_lptim_clock": 4

Power measurement BLE Advertising with:
"target.lpticker_lptim": 1, "target.lpticker_lptim_clock": 4

Target(s) affected by this defect ?

NUCLEO-WB55RG

Toolchain(s) (name and version) displaying this defect ?

ARM Compiler 6.15

What version of Mbed-os are you using (tag or sha) ?

Mbed OS 6.10

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed Studio: 1.4.0

How is this defect reproduced ?

1. Upgrade BLE Stack to Release v1.11.1 BLE Stack
2. Use the BLE_GattServer_AddService from Mbed BLE Examples.
3. Change the advertising intervall e.g:

        ble::AdvertisingParameters adv_parameters(
            ble::advertising_type_t::CONNECTABLE_UNDIRECTED,
            ble::adv_interval_t(ble::millisecond_t(1024)),
            ble::adv_interval_t(ble::millisecond_t(3072))
        );

4. Add "target.lpticker_lptim_clock": 4 to mbed_app.json
5. measure power consumption

[jeromecoutant]

Hi

Note that changing lpticker_lptim value has not been verified and then not supported.

Why did you try that ?

[mayrhomar]

Hi @jeromecoutant
Sorry, I did not know that this is not supported.
However, the problem also occurs without changing lpticker_lptim. You can see this in the second image. (lpticker_lptim =1 is default?)

[jeromecoutant]

(lpticker_lptim =1 is default?)

Yes: https://github.com/ARMmbed/mbed-os/blob/master/targets/targets.json#L4166

However, the problem also occurs without changing lpticker_lptim. You can see this in the second image.

Could you describe more what you see in this image ?

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-3843

[mayrhomar]

Of course,
the advertising interval is set to 2047 ms. The high current peak comes from the advertising. The small current peak comes from the lpticker. (with "target.lpticker_lptim_clock": 4 ticker interval = 8 seconds)
After the first advertising current peak, the microcontroller does not switch to deepsleep mode. After the lpticker interrupt (second 14.5) the microcontroller switches back to DeepSleep.

This could cause me to have a high power consumption for eight seconds in the worst case.
with: "target.lpticker_lptim_clock": 1 it would be two seconds.

Please correct me if I misunderstood something.

[jeromecoutant]

Going to sleep or deepsleep in idle state is an OS decision.
Application/drivers can limit the choice calling sleep_manager_lock_deep_sleep() function.

After a quick check where this lock is called, maye, you can check if you are not using other IP like CAN/SPI/SerialBase/USB/... where maybe some lock call is not unlock before going in idle state ?

Last comment would to be to check latest 6.10 release (including 1 small fix in mbed ticker).

[mayrhomar]

Hi @jeromecoutant

I am only using the Mbed BLE example. I do not use any other IP. I tried to find the problem (SleepLocks) with the Sleep Tracer. Unfortunately this does not work properly, I get a never ending data stream with sleep tracing enabled:

LOCK: lp_ticker.c, ln: 471, lock count: 1
UNLOCK: lp_ticker.c, ln: 341, lock count: 0
LOCK: lp_ticker.c, ln: 471, lock count: 1
UNLOCK: lp_ticker.c, ln: 341, lock count: 0
LOCK: lp_ticker.c, ln: 471, lock count: 1
UNLOCK: lp_ticker.c, ln: 341, lock count: 0
...

However, this probably has nothing to do with the BLE problem. The SleepTracer does not work for me even without BLE enabled.

Last comment would to be to check latest 6.10 release (including 1 small fix in mbed ticker).

With mbed os 6.10 I get the same results.

[LMESTM]

@mayrhomar are we sure this is the application which doesn't enter deep sleep, or may it be the controller part ?
In later case, have you used an up-to-date controller version ?

[mayrhomar]

@LMESTM

are we sure this is the application which doesn't enter deep sleep, or may it be the controller part ?

It could also be the controller part. As I understand it, the advertising only runs on the BLE stack without affecting the application. The problem always occurs after sending out the advertising data. Maybe the BLE stack could cause the problem?

In later case, have you used an up-to-date controller version ?

But I am using the current BLE stack. I just updated today to the latest stack (release v1.11.1).

Could the problem be reproduced?

[LMESTM]

So you've udated the controller with latest version from here ?
https://github.com/STMicroelectronics/STM32CubeWB/tree/master/Projects/STM32WB_Copro_Wireless_Binaries/STM32WB5x

This needs to be added to the to-do list as it will take time to reproduce and analyze.

[mayrhomar]

So you've udated the controller with latest version from here ?
https://github.com/STMicroelectronics/STM32CubeWB/tree/master/Projects/STM32WB_Copro_Wireless_Binaries/STM32WB5x

Yes, I tried with Release v1.11.0 and now with Release v1.11.1.