Reduce BLE power consumption

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
RoDe_1773541
Level 4
Level 4
25 replies posted 10 replies posted 5 replies posted

I'm using the BCM4343WWCD_EVB with WICKED SDK 3.5.2 and when I enable the bluetooth stack the power consumption doesn't drop below 9mA.  Calling wiced_platform_mcu_enable_powersave doesn't have any effect.  Is there a way to reduce the power consumption?  I'm going to be running this device off of batteries and 9mA is very high. 

Thanks,

-Rob

25 Replies
Anonymous
Not applicable

What are you enabling on the BT stack? What mode are you using and what profiles and features?

The power consumption and management will depend on these aspects.

0 Likes

nsankar

I'm just using the stock ble_hello_sensor snip.

0 Likes

nsankar wrote:

What are you enabling on the BT stack? What mode are you using and what profiles and features?

The power consumption and management will depend on these aspects.

Hi nsankar​,

I think the point is "Calling wiced_platform_mcu_enable_powersave doesn't have any effect."

A similar report here:

https://community.broadcom.com/thread/6886

0 Likes
Anonymous
Not applicable

Power consumption for the solution is a combination of MCU, WLAN and BT

So just calling MCU powersave would not automatically save power. MCU powersave is working

But in order for MCU powersave to be effective both WLAN and BT device components and software components have to cooperate

And in this the mode in which the WLAN and BT are being used is important

For example if the WLAN is being used as softAP - then calling MCU powersave to enable MCU powersave will do not much because the networking thread will be active most of the time and will keep the RTOS from putting the MCU to sleep mode

Same with the BLE stack. Hence my question on the use-case is relevant and this issue doesn't have anything to do specifically with the MCU powersave API

Having said that we will take a look at why enabling the BT/BLE stack does not allow the system to go to sleep more effectively to save power.

Also quite interested in enabling MCU deep sleep while the BLE part is advertising or connected.  I'm not sure if I've got it right that the WAKE lines on the BLE parts are provided with this in mind.   Seems like a pretty important issue with designing BLE devices as MCU power consumption can be a couple orders of magnitude larger than BLE power consumption.

Any progress in enabling the MCU powersave in this realm?

0 Likes
Anonymous
Not applicable

Hi nsankar,

Any process in BLE powersave consumption?

I got a Avnet BCM4343W IoT Starter Kit. Can you provide any examples or docs to reduce BLE power consumption? I try many ways to reduce BLE power consumption, but always large than 10mA!

Hope for your help!!

0 Likes
AndrewY_86
Employee
Employee
25 sign-ins 25 replies posted 10 replies posted

robjderr

Just a recommendation, try calling wiced_platform_mcu_enable_powersave both before and after wiced_bt_stack_init.

  Boot --- wiced_platform_mcu_enable_powersave -- bt_stack_init -- wiced_platform_mcu_enable_powersave

~8.4mA                        ~1mA                                         ~8.9mA                ~1.2mA

Let me know if you observe the same results

peter_fenndjjwdstudejio

aky

I've tried that and the Bluetooth stack becomes unstable.

-Rob

0 Likes

I'll try this but like implied here, this seems to be circumventing the

power save lock system in place. the lock is behind held by the BLE stack

for a reason.

I'm currently getting back to basics trying to get the RTC wake up on the

stm32f412 to work. when enabling the rtc, compiles failed so not sure when

this was last tested.

For STM32F4xx:

Another barrier to very low power consumption.

the use of the following line in powersave prevents the clock from turning off in stop mode.  This ensures you can still use JTAG to your device, but the clocks remain running which will consume several mA.

DBGMCU->CR |= 0x03; /* Enable debug in stop mode */

removing this will allow the clock to halt.  ***CAREFUL*** if you program a MCU that immediately goes to deep sleep it will be very difficult to program after that.

Still, when BLE threads are enabled, powersave mode does not occur.

I've checked my BT_HOST_WAKE signal on the MCU GPIO, and it seems to be asserted.  Added an edge trigger and it does not change.  So I'm not sure what is causing this but we are now hitting a strong dead end on this issue.

We will continue to investigate on the 94343WWCD1 board as well.

My check of the BLE library seems to reveal some wake type functions, but it's not really feasible to understand how they work and troubleshoot this issue further.

nm -l bluetooth_low_energy.ThreadX.NetX_Duo.ARM_CM4.release.a |grep wake

00000001 T hcill_wake_up_bb

00000001 t hcilp_start_bt_wake_idle_time

00000001 T bte_hcisu_lp_wakeup_host

So, as it stands, BLE (versus bluetooth) does reduce the wireless current a good bit, but with the MCU unable to sleep, this is a no go for most systems where BLE is required - "wearable" type scenarios.   And this issue has been known and outstanding for 6 months.   I hope Cypress is assigning a very high priority to this issue - as it will result in a lot of folks looking to design wearables going elsewhere.

mwf_mmfae

Anonymous
Not applicable

Hi aky,

I try it, but can't get the same results.

I found that the F411 can't enter into sleep mode when use BLE.If I only run blinky, F411 can enter into sleep mode.

0 Likes
dast_1961951
Level 4
Level 4
10 likes received First like received

Some further notes I have found in investigating this:

*  It doesn't appear that the BLE stack reads the HOST_WAKE signal at all.  it seems to read CTS from BLE device.

*  BLE stack appears to have a hard-coded timer that runs all the time.  It wakes every 100 ms and probably reads CTS and handles some timing (advertisement rate changes).  Having a hard-coded timer like this is another issue in trying to maximize sleep sequences.  *  BLE stack blocks deep sleep because it's always stuck in the BLE UART wiced_uart_receive_bytes() call, which disables powersave.

Quite a few high-level architecture issues that give one the idea that the BLE stack as not designed for such lower power.

Looking forward to some insight as to when/if deep sleeping will be supported here.

mattl_01
Employee
Employee
100 replies posted 50 replies posted 25 replies posted

DaveStude

I'm told that there is an issue with the Bluetooth stack and the UART driver.

Further, I'm told that the Bluetooth stack problem was fixed in 4.1.  Has anyone on this thread tried 4.1?

I'm checking the status of the UART fix.

Thanks,

--Matt

As far as I understand, the 4.1 release does not include the ability to get MCU deep sleep ("stop mode" in STM32Fxxxx). 

0 Likes

OK, here is where we stand.

There are three issues contributing to the problem:

  1. Bluetooth stack issue (fixed in 4.1)
  2. UART driver issue (Fix currently under test, will be released in WICED 5.0)
  3. “stop mode” for the STM32Fxxxx (Same as item 2)

WICED 5.0 is scheduled for late April / Early May.

--Matt

mdl wrote:

OK, here is where we stand.

There are three issues contributing to the problem:

  1. Bluetooth stack issue (fixed in 4.1)
  2. UART driver issue (Fix currently under test, will be released in WICED 5.0)
  3. “stop mode” for the STM32Fxxxx (Same as item 2)

WICED 5.0 is scheduled for late April / Early May.

--Matt

It means people have to wait for more than one month to get the fix?

It would be helpful if you just post the fix at least for 2, so people can help testing it.

BTW, Does 1 fixed in sdk-3.7.0-7?

0 Likes
mattl_01
Employee
Employee
100 replies posted 50 replies posted 25 replies posted

Updating the schedule and providing some additional information.

WICED 5.0 release is now scheduled for late May.  All three items mentioned above are fixed.

Also, this from R&D

"We have a sample app ‘ble_hello_sensor’ that demonstrates the sequence to enter/exit power save mode both on the ST-MCU and 4343W chip. We have also measured the system current on BCM94343WCD1.  It is <1.5mA with BT advertisements enabled. "

Thanks for everyone's patience on this.

--Matt

0 Likes

mdl wrote:

Updating the schedule and providing some additional information.

WICED 5.0 release is now scheduled for late May.  All three items mentioned above are fixed.

I don't get it.

Nobody get benefit if you don't release the fix.

(It's not about if you fixed it or not, it's about if you can deliver the fix.)

Postponing the release schedule is a bad thing as there are other bugs in the closed source libraries.

People are *waiting* for your SDK update to address bugs.

0 Likes

mdl wrote:

OK, here is where we stand.

There are three issues contributing to the problem:

  1. Bluetooth stack issue (fixed in 4.1)
  2. UART driver issue (Fix currently under test, will be released in WICED 5.0)

Can you tell me what is the problem of UART driver issue?

If the fix is not in closed source library, can you just post the fix on the forum?

0 Likes

I can ask R&D for more details on the UART driver issue, but I'd prefer to let them continue cranking on getting the release out.

I'll copy this from an email thread I saw.  Maybe it's enough detail.


The UART block was not being initiated properly before or after entering sleep, which caused the host processor not go to sleep completely.

--Matt

0 Likes

Agree we must keep our team focused on releasing the SDK 5.0, it's the priority.

I do have this additional text to add from one of our experts:

BLE Low Power mode is enabled by default in our BTEWICED stack in the SDK. We only need to make sure that the GPIOs corresponding to DEV_WAKE and HOST_WAKE are connected between the 4343W and MCU.

Now for the caveat (there had to be one, eh) – But in spite of the 4343W going into low power mode (in the order of uA), the overall system current drawn was 15-20mA even when the ST was put in powersave enable mode. This is due to the WICED UART driver on ST platform not being sensitive to power save. As you know the 4343W BT is connected to the MCU over UART. The UART driver code was turning off powersave in its entry section and this was one of the root-causes. Besides, we also had to get the MCU wakeup on interrupt code programmed to wake up the MCU and re-configure UART whenever the HOST_WAKE line is asserted. anyu

Adding user_114741021​ and djjw

0 Likes

Shawn Antol wrote:

Agree we must keep our team focused on releasing the SDK 5.0, it's the priority.

I just want to point out it's fine to have incremental fixes in follow up releases.

The FreeRTOS users already wait for the sdk update for very long time due to missing FreeRTOS support in sdk-4.x serial.

If a feature takes time, it's fine to put it in next release. Don't block current release.

There is no benefit to delay release schedule this way. (The blocking issue might not impacted by most of the users).

0 Likes

Fair points.

0 Likes