search

ARMmbed / mbed-os

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

BLE power consumption #11745

Closed Mario-N closed 3 years ago

Mario-N commented 5 years ago

Description of defect

BLE power consumption

In Mbed BLE button example the BLE module IDB05A1 current is too high, average 2.8mA. I'm measuring the current consumption through Jumper J1 of IDB05A1, so I'm measuring only the current flowing into BLE module. I made some measurement also with oscilloscope and I can see a base current of about 2.8mA with spike during advertising of about 13mA.

Target(s) affected by this defect ?

Nucleo F401RE together with IDB05A1 BLE shield.

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

Mbed Online compiler

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

MBED OS 5.14.0

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

Mbed Online compiler, I tried also MBED studio 0.7.0.16 with release building profiles

How is this defect reproduced ?

To reproduce: Nucleo F401R, IDB05A1 BLE shield, Mbed BLE button example

0xc0170 commented 5 years ago

@ARMmbed/team-st-mcd Please review

bsturgess commented 5 years ago

Hi, I having the same issue on NRF52-DK, same power results, around 13ma!!

Also, BLE Beacon example (once printf is removed) results in 900ua power consumption.

The issue seems to be related to not being able to deep sleep

Results from logger Uptime: 2001 Sleep time: 1930 Deep Sleep: 0 Uptime: 4001 Sleep time: 3864 Deep Sleep: 0 Uptime: 6001 Sleep time: 5798 Deep Sleep: 0 Uptime: 8001 Sleep time: 7733 Deep Sleep: 0 Uptime: 10001 Sleep time: 9667 Deep Sleep: 0 Uptime: 12001 Sleep time: 11601 Deep Sleep: 0 Uptime: 14001 Sleep time: 13535 Deep Sleep: 0

jeromecoutant commented 5 years ago

@avilei

adbridge commented 5 years ago

@Mario-N You have removed the template fields from the issue header. Could you please put them back and fill in the template accordingly as per the guidelines? Thanks

Mario-N commented 5 years ago

@Mario-N You have removed the template fields from the issue header. Could you please put them back and fill in the template accordingly as per the guidelines? Thanks

Thanks Anna, It should be correct now

Mario-N commented 4 years ago

Any update regarding this problem? I'm stuck with the project.

40Grit commented 4 years ago

Can you provide a dump of the peripheral registers right before the WFI/WFE instruction that would put the part to sleep?

Mario-N commented 4 years ago

I can use MBED Studio, but I need a little instruction on what you exactly need. What is WFI/WFE instruction you mentioned?

avilei commented 4 years ago

@Mario-N if you're measuring via Jumper J1 of X-NUCLEO-IDB05A1, you will get the current consumption of the BlueNRG-MS chip only. The value you read depends on the state the chip, e.g. advertising vs connected, connection parameters, and so on.

Connected mode consumes much less than advertising. When connected, the longer the connection interval, the lower the consumption.

There is a current estimation tool made by ST that you can use to check the estimated consumption based on different settings. It's available here: https://www.st.com/content/st_com/en/products/embedded-software/wireless-connectivity-software/stsw-bnrg001.html

Could you please check that the values you get are similar to the ones reported by the tool?

Also, if you need a reference measure with your hardware setup, you may want to try the low-power implementation for BlueNRG-MS based on STM32Cube. The reference for optimized consumption is the SampleApp_DMA_LowPower project in the X-CUBE-BLE1 SW package, available here: https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-ble1.html

Mario-N commented 4 years ago

@avilei As you said I'm measuring only the current of the BLE module. I modified the Mbed BLE button example in order to be able to measure the current at various initialization points. Here the code with the current in mA measured: `int main() { pc.attach(&onCharReceived); while(1) 3mA { if(c =='n') break; } c=0; pc.printf("Instance\n"); BLE &ble = BLE::Instance(); 0.662mA while(1)
{ if(c =='n') break; } c=0; pc.printf("Events\n"); ble.onEventsToProcess(schedule_ble_events); 0.662mA while(1) { if(c =='n') break; } c=0; pc.printf("Demo events\n"); BatteryDemo demo(ble, event_queue); 0.662mA while(1) { if(c =='n') break; } c=0; pc.printf("Start\n"); demo.start(); 2.878 - 2.928mA pc.printf("Dopo start\n");

return 0;

}`

Current during Advertising at 1140ms 2.878 - 2.928mA Current when connected 2.928mA Measures with Fluke 8060A multimeter. Compared with the ST tool is really too much. Then I flashed STM32CubeExpansion SampleApp_SERVER_F401RE.bin. Wow that's the desired current consumption about 2uA during advertising and 33uA when connected. At this point the HW works great, there must be a bug with cordio stack.

apalmieriGH commented 4 years ago

@Mario-N alternatively, you may use this pre-cordio implementation of X-NUCLEO-IDB05A1 driver in order to make another comparison.

Mario-N commented 4 years ago

@apalmieriGH Thanks for suggestion Andrea, do you have an example on how to use that library. I don't know how to use it.

apalmieriGH commented 4 years ago

@Mario-N please, refer to this one for mbed classic.

Mario-N commented 4 years ago

@apalmieriGH Thanks Andrea, I tryed the example, it works and the consumption is around 2uA. Unfortunately if I use it with MBED-OS 5 it doesn't work. I've already developed all my application using the last OS revision, so this implementation is not feasible for me. I hope someone could help me.

apalmieriGH commented 4 years ago

@Mario-N tag mbed-os-5.9.6 of the BLE examples still uses the pre-cordio implementation for BlueNRG. Hope this can help.

avilei commented 4 years ago

@Mario-N @MarceloSalazar @pan- Andrea's example is an old one using the BLE host implementation of ST's BlueNRG-MS chip. Latest versions of Mbed OS have embraced the BLE host implementation provided by the Cordio stack. This raises the question about which is the best course of action when users would like to have alternative BLE host implementations for optimization purposes (e.g reduced footprint and/or low power consumption).

pan- commented 4 years ago

@avilei is it expected from the BlueNRG-MS chip to consume more power when operating in HCI mode ? Could it be dependent of the version of the firmware being used ?

40Grit commented 4 years ago

If someone can provide a way to dump the periph registers for both the lower power binary and the latest higher power binary @avilei Can then do a diff on the two dumps and see what Mbed OS is now configuring differently.

This cuts straight to the answer unless silicon errata or other off chip component is involved in the consumption.

@flit anything in pyocd to do this?

Mario-N commented 4 years ago

As suggested by @apalmieriGH I tested ble with mbed-os-5.9.6 and the consumption is correct, 2uA. Unfortunately that BLE implementation is not working with the latest mbed release I have to use with my development due to, vice versa, with 5.9.6 USBMSD is not working. Any suggestion?

pmancele commented 4 years ago

Same here, we have a high power consumption with cordio, and we can't send notifications as fast as we used to do previously. Like mentionned in #12602

ciarmcom commented 4 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-2303

DBS06 commented 4 years ago

Same here and there #10669

pan- commented 4 years ago

@avilei @apalmieriGH Is it possible that the sleep management of the IDB05A1 is not effective when the controller operates in HCI mode instead of ACI mode ? The power consumption measured here is the power consumption of the module, not the board.

andy-kogsys commented 3 years ago

Any updates on this issue? I am facing similar problems on an nRF52.

ciarmcom commented 3 years ago

We closed this issue because it has been inactive for quite some time and we believe it to be low priority. If you think that the priority should be higher, then please reopen with your justification for increasing the priority.

andy-kogsys commented 3 years ago

I believe this is high priority, and would echo my comments on #10669

bsturgess commented 3 years ago

Whoever thinks this is a low priority needs their head checking

On Wed, 20 Oct 2021, 16:28 ARM mbed CI, @.***> wrote:

We closed this issue because it has been inactive for quite some time and we believe it to be low priority. If you think that the priority should be higher, then please reopen with your justification for increasing the priority.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ARMmbed/mbed-os/issues/11745#issuecomment-947781038, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAW4SX3N2EIQG5ZR3PTFSRLUH3NYJANCNFSM4JEU4ETA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.