BLE power consumption using CORDIO stack too high

[sagrebin]

Description of defect

I've cloned the mbed-os-example-ble repo and removed the LED blinking code and the print statements. When I run the application on my dev board and use nordics power profiler I get an average of 1mA when advertising (advertising interval: 2 sec).
I did the same with the with the deprecated sample BLE_BatteryLevel which uses nordics soft device and I get around 20uA when advertising.
I use a custom dev board with the ublox NINA-B112 module, there are no other components on the board which could consume power.

Target(s) affected by this defect ?

NRF52_DK

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

GCC_ARM

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

a4738fa

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

mbed-cli 1.10.0

How is this defect reproduced ?

See the description above

[40Grit]

If debugging with an .svd loaded,

are you able to confirm which peripherals are enabled and running between the two examples?

Also would be interesting to see the clock configurations between the two.

[40Grit]

Mistyped .svd above.

[yogeshk19]

@40Grit We are seeing similar power consumption and at times even higher than 1ma during advertisements. One of the other issues, had listed out disabling the cryptocell and here is what the mbed_app.json looks like. Ours is a custom board with NRF52840 BLE module. We are using Cordio API without the Nordic Softdevice.

{ "target_overrides": { "NRF52840_DK": { "target.features_add": ["BLE"], "target.extra_labels_add": ["CORDIO", "CORDIO_LL", "SOFTDEVICE_NONE", "NORDIC_CORDIO"], "target.features_remove": ["CRYPTOCELL310"], "target.macros_remove": ["MBEDTLS_CONFIG_HW_SUPPORT"], "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_S140_FULL", "NORDIC_SOFTDEVICE"], "platform.stdio-baud-rate": 115200, "platform.default-serial-baud-rate": 115200, "target.console-uart-flow-control": null } } }
Thanks,
Yogesh

[40Grit]

My questions above are wondering what soft device does with the clocks/peripherals/radio settings in order have significantly lower power consumption than cordio stack.

[0xc0170]

My questions above are wondering what soft device does with the clocks/peripherals/radio settings in order have significantly lower power consumption than cordio stack.

cc @ARMmbed/mbed-os-pan

[40Grit]

@sagrebin , @yogeshk19 To provide further clarity to my vague posts above.

Are either of you able to dump the peripheral registers when using softdevice and when using cordio?

The diff between the two dumps could provide some insight since the softdevice sources are closed.

[yogeshk19]

@40Grit Sorry I haven't had a chance to dump the peripheral registers. I am planning on re-running my power draw tests again after the next mbed-os release which is supposed to have updates to hci driver i believe. I am not planning on using the softdevice at this point, only the Cordio API as is.

[sagrebin]

@40Grit I was hoping that with the arrival of nordics sdk 15 it would be fixed by unfortunately its not. I've dumped the registers:
cordio: https://pastebin.com/i1q4T08m
nordic SD: https://pastebin.com/47XEkrBh

[pan-]

From the diff it looks like the LFCLK is synthesized from the HFCLK when Cordio is used. That might be one of the cause of the high power consumption.

[sagrebin]

Indeed, for some reason the NRF_LF_CLK_SRC is set to CLOCK_LFCLKSRC_SRC_Synth in NRFCordioHCIDriver.cpp
#if MBED_CONF_NORDIC_NRF_LF_CLOCK_SRC == NRF_LF_SRC_SYNTH #define NRF_LF_CLK_SRC CLOCK_LFCLKSRC_SRC_Synth
But what I don't get is why MBED_CONF_NORDIC_NRF_LF_CLOCK_SRC is set to NRF_LF_SRC_SYNTH. Every definition I can find is set to NRF_LF_SRC_XTAL

[40Grit]

@AGlass0fMilk

[ghost]

@sagrebin : so you see NRF_LF_CLK_SRC set to NRF_LF_SRC_XTAL in mbed_config.h ?

[kleunen]

I have seen the same issue. I am not sure if it is the crystal configuration, I tried changing back the crystal to XTAL, in the initComplete of the BLE stack. But this does not seem to help.

[bsturgess]

Same issue here too. watching...

[40Grit]

The best way to get a picture of what is going on is to dump the peripheral and cpu registers between the two examples you are comparing power for.

Then do a diff of the dumps.

It needs to be considered as well that if a gpio is left in an output state it may result in leaks to other unpowered components on a board.

Additionally the pull resistors internal to the gpios for this part are pretty strong. Deffinitely confirm the state of your gpios.

[bsturgess]

I've checked the consumption before the ble.init and its 3ua, so roughly what it should be.

I can also see that the device just doesn't deep sleep after ble init, see logs below, 0 time in deepsleep :( ...

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

[bsturgess]

What is the code for dumping the registers? Thanks

[40Grit]

Should be able to do it through gdb command line or pyocd. J-link commander maybe if using j-link

[40Grit]

you will need to load the .svd file for your target mcu

[bsturgess]

Is this being looked at internally by the ARM team? If so i'll just keep on using SoftDevice until resolved

[40Grit]

Latest news is that the BLE PAN team is busy.
Also the Cordio team was let go in April and became PacketCraft Inc.

Embedded Planet, my employer, will probably be looking into this over the next couple months but no promises.

Not sure how Cordio governance is going to go moving forward. PacketCraft is probably the new maintainer.

[40Grit]

Also softdevice has its own RTOS internally. I have heard and experienced that it doesnt play very nice with external RTOS's.

[ghost]

and there's no history at their github repo https://github.com/packetcraft-inc/cordio. How can anybody really keep track of what they are up to?

[pentabarf]

I've checked the consumption before the ble.init and its 3ua, so roughly what it should be.

I can also see that the device just doesn't deep sleep after ble init, see logs below, 0 time in deepsleep :( ...

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

I noticed that there is a deep sleep lock in the Cordio idle_hook. (I am using nRF52)
And it gets called when there is nothing to do i guess. Possibly this has an effect on deep sleep
See in mbed-os/targets/TARGET_NORDIC/TARGET_NORDIC_CORDIO/TARGET_NRF5x/NRFCordioHCIDriver.cpp

static void idle_hook(void)
{
[...]
// critical section to complete sleep with locked deepsleep
core_util_critical_section_enter();
sleep_manager_lock_deep_sleep();
sleep();
sleep_manager_unlock_deep_sleep();
core_util_critical_section_exit();
}

[kleunen]

@pentabarf You are right

It actually says in the documentation:
https://github.com/ARMmbed/mbed-os/blob/master/features/FEATURE_BLE/targets/TARGET_NORDIC/TARGET_NORDIC_CORDIO/TARGET_NRF5x/README.md

Resources used:
HF clock is enabled

That is just complete BS, this really removes LE from BLE.

[yogeshk19]

@40Grit, @pan- I was wondering based on @pentabarf and @kleunen comments, is there any progress on helping improve the power consumption? Currently our application we have built which advertises 90% of the time and 10% time stays connected, the avg. power consumption is 200 uA when advertising and 300 uA when connected using the Cordio API. When using the softdevice the power draw is around 20 uA when advertising and 9-12 uA when connected. This clearly indicates the Cordio platform is consuming more power than when just using Nordic's softdevice to build a similar application.

As mentioned by you earlier that Cordio is no longer the priority for ARM and a different company has taken over the development effort, but I am wondering when companies like mine migrated to Cordio platform assuming that this was the better platform to be on since ARM supported this new platform for BLE and that something so important as BLE Power consumption needs to be handled, what is the escalation mechanism to get either ARM or the new company to address this issue? This issue has been lingering from 9 months now, with no clear priority or resolution in sight.

Sorry just venting out!

Thanks,
Yogesh

[0xc0170]

Thanks @yogeshk19 for the feedback. I'll share this with relevant people.

[yogeshk19]

@andypowers any updates on this issue and is there a fix anticipated for this issue and will it be back ported to mbed 5? I believe this question was asked April 10th of this year and no response!

At the least I would hope the MBED BLE and Packet Craft team to provide a realistic expectation to the consumers of their product. As of today it is more than 2 years and I have never seen a professional organization deal with an issue in this fashion as to not even respond and provide some kind of feedback as to what the MBED team is doing to resolve this issue. This is a serious issue that prevents us from leveraging the BLE feature effectively.

I am hoping someone serious enough in the MBED team can either say we will fix this issue or close this issue for good, because its been 2 years since this issue was opened, with no resolution in sight.

Thanks,
Yogesh

[ghost]

so .. you're paying for support from arm and not getting the help you need @yogeshk19 ?

[pan-]

@yogeshk19 We received a preview of the packetcraft patch that improve the power consumption. It will be integrated when the Cordio stack has been updated to the latest version (#14798).

I don't know if it will be back-ported to Mbed OS 5.15 or not. That could be a complex operation as it depends on platform and stack support which have evolved in Mbed OS 6. However it shouldn't be too complex to back-port the Bluetooth API from Mbed OS 6 into Mbed OS 5.

[yogeshk19]

@pan- Thanks for taking the time to update regarding any progress in this issue. The last time I had asked what is the escalation mechanism and you looped in @andypowers to see if there can be some larger visibility within the ARM MBED BLE team to address this issue sitting for over 2 years. But as you can see from the issue thread, @andypowers hasn't even acknowledged with any response. My point is can we get a release timeframe or commitment from ARM MBED BLE team as to when this would be fixed and made available to be consumed even if it is only going to be fixed in MBED 6?

This would help us in planning on migrating our existing products that we have built using the CORDIO BLE Stack from MBED 5 to MBED 6 in a more deterministic fashion.

Thanks,
Yogesh

[pan-]

I think the patch will land in ~4 weeks from now in mbed os 6.

[pentabarf]

I think the patch will land in ~4 weeks from now in mbed os 6.

4 weeks are over. are there any news to this?

[paul-szczepanek-arm]

We have updated the cordio stack to the new version (in the feature branch https://github.com/ARMmbed/mbed-os/tree/feature-ble-cordio-21.04) but we are still waiting for the patch that goes with it.

[pentabarf]

We have updated the cordio stack to the new version (in the feature branch https://github.com/ARMmbed/mbed-os/tree/feature-ble-cordio-21.04) but we are still waiting for the patch that goes with it.

I did a fast test. just compared my application with mbed-os-6.13.0 and feature-ble-cordio-21.04:
With mbed-os-6.13.0 i have a current consumption of 1.2 - 1.6 mA
with feature-ble-cordio-21.04 it is around 3.2 - 4.0 mA

[andy-kogsys]

@paul-szczepanek-arm, @pan, any updates on the patch?

[bsturgess]

So 5.11 is still the latest version we can use on NRF52832? So nutty, this is one of the most popular mcu's in the world of IoT.

…

On Mon, 13 Sep 2021, 14:59 andy-kogsys, ***@***.***> wrote: @paul-szczepanek-arm <https://github.com/paul-szczepanek-arm>, @pan <https://github.com/pan>, any updates on the patch? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10669 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW4SX7AVCNADL65DBAHCA3UBX7UVANCNFSM4HPTFNRQ> . 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>.

[stevensam2013]

We have also been waiting keenly for this for a long time now and it is seriously impacting our product development. When will this issue be resolved?

[ciarmcom]

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]

I believe this is a high priority, given that without it mbed is unable to achieve low power BLE performance on NRF52 hardware. To help with your justification:

• The current consumption reported on this thread using mbed is ~1 mA. ~20 uA is achievable using the Nordic stack, or indeed with Zephyr.
• NRF52 is a highly popular platform.
• This issue has been reported by multiple users (this thread and others) and has persisted for over 2 years.

I'd suggest that this makes it a high priority and I believe others would agree @stevensam2013 , @bsturgess , @pentabarf , @yogeshk19, @Heinera79 , @apcurtiss .

Speaking for myself I would like to use mbed for some new projects, but we are being forced towards Zephyr specifically due to this issue.

[CodingGhost]

Wow. This is definitly not low priority, it should be one of the highest BLE priorities.
Me and my team Switched to zephyr A YEAR ago because of this issue, and now its "low priority".
I can only suggest also moving to zephyr for everyone that has this problem as it obviously has no priority here.

[andypowers]

It is a high priority, and the team are validating a fix from Packetcraft at the moment. The issue was closed by mistake. I've reopened it.

[stevensam2013]

This is definitely a high priority issue, and it has been ongoing for a long time now. This issue is for the nRF52 which is an extremely popular chip and many of us expect this to work correctly with mBed.

This bug makes it unfeasible to use the nRF52 in a product and needs to be rectified.

Please re-open this as high priority.

Additionally, please provide an update on the patch that was expected to resolve this issue for mbed os 6 late July.

[otoshi1205]

Is there any roadmap for this issue to be resolved? We're developing an IoT solution with NRF52 and this issue is the main blocker for our power optimization milestone. I tried to use the latest commit from https://github.com/ARMmbed/mbed-os/tree/feature-nrf52-low-power-ble branch. It fixes the high power consumption issue, but the MCU gets stuck in the idle thread after ~9 minutes of work. I can provide additional info if needed.

[yogeshk19]

@andypowers @pan- @0xc0170 I was wondering if there was any progress made on this issue. Its been almost 3 years since this bug was opened and according to @andypowers "It is a high priority, and the team are validating a fix from Packetcraft at the moment." was mentioned last October. I still don't see progress called out in regards to this issue? Can one of you take the time to comment on the progress on this issue?

Also it seems like it would be valuable if the MBED team won't fix this issue, they should clearly call it out and close this issue. At the least this would be some progress regarding this issue instead of staying in this limbo state for almost 3 years.

Thanks,
Yogesh