search

ARMmbed / mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things
https://mbed.com
Other
4.67k stars 2.98k forks source link

[BLE] STM32WB55 advertising DeepSleep Bug #14580

Closed mayrhomar closed 2 years ago

mayrhomar commented 3 years ago

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 WB55_Power_Adver

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

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))
        );
  1. Add "target.lpticker_lptim_clock": 4 to mbed_app.json
  2. measure power consumption
jeromecoutant commented 3 years ago

Hi

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

Why did you try that ?

mayrhomar commented 3 years ago

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 commented 3 years ago

(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 commented 3 years ago

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 commented 3 years ago

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": 1it would be two seconds.

Please correct me if I misunderstood something.

jeromecoutant commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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.

0xc0170 commented 2 years ago

As it's been a year without any update, I'll close this as won't fix.