BCM20736S Sleep Example Firmware

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

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hello,

  I have attached firmware files that are a straightforward modification of the hello_sensor app for the BCM20736S/BCM20736 for use with SDK2.0.1 and beyond.  The firmware and Word document outline the steps to make use of DEEP SLEEP/HidOff modes.  The example shortens the Advertising duration to 30 seconds if after 30 seconds the device has not connected then the Device will go into DEEP SLEEP.  The other scenario that will cause the device to go into DEEP SLEEP is if it has established a connection and then the connection has been closed.  The firmware details and Power Consumption measurements are outlined in the Word Doc.

Happy Programming!!

Regards,

Frank

20 Replies
lock attach
Attachments are accessible only for community members.
SuLe_1710756
Level 5
Level 5
10 likes received First like received First like given

Hi, Frank

First, thank you for example application related to deep sleep, but I have some questions.

It was estimated about 500uA in deep sleep mode when I checked current consumption by using your example.

I verified the current consumption after stopping advertisements and 30 secs timeout, also after link disconnection.

I tested it with DC/DC output 1.8V like your test environments using coin cell and SDK 2.0.1 & BCM920737TAG board.

Could you let me know why this results caused in my environments? I posted my tested code which is almost same your code.

Thanks,

SM

fdroberts2

0 Likes
Anonymous
Not applicable

Hello Sung-Mok,

  I am not sure where you are coming up with 500uA?  The Word Document that is attached here shows Power Consumption Graphs that clearly show the Avg Current in Deep Sleep of just above 1uA?  Can you help me understand where you came up with 500uA for DEEP SLEEP?

This is the Power Graph that was recorded during Deep Sleep and that is in the WORD DOC attached above.

HIDOff:  Device will enter HIDOff after it has Advertised for >30seconds and no connection OR after it has connected to a device and the connection has been lost. This is how the my_App.c firmware works which is a simple modified version of the hello_sensor app in SDK2.0.1. Device will wake-up after pressing a GPIO that has been defined as an Interrupt, such as P0 which is defined in platform.h as the Push-button.

pastedImage_0.png

Zooming into the Peaks while in DEEP SLEEP it shows the following which I am still not 100% clear where these peaks come from during DEEP SLEEP but I am assuming it is something like the Keyscan or something that is still operating during DEEP SLEEP.

HIDOff Peaks:  Zoomed in view to see pulses that are occurring every ~82ms with peaks of >120uA’s.  You can still see the Average Current shown on the right side of the graph is 1.35uA between the selected range and the running average is 1.42uA.

pastedImage_3.png

Regards,

Frank

Anonymous
Not applicable

Hi embeddedmasters,

Thank you for your BCM20736S Sleep Example Firmware .I have some related questions about sleep mode's power consumption BUT with connection enabled.

Here are my steps, followed by the 3 questions at the end.

I tested your Sleep Example code with my board. But, to ensure no GPIO pins can draw any current (to get to minimal power consumption possible), I disabled all GPIO pins as follow:

Here is your original code with 3 GPIO pins enabled:

const BLE_PROFILE_GPIO_CFG my_APP_gpio_cfg =

{

    /*.gpio_pin =*/

    {

        GPIO_PIN_WP,      // This need to be used to enable/disable NVRAM write protect

        GPIO_PIN_BUTTON,  // Button GPIO is configured to trigger either direction of interrupt

        GPIO_PIN_LED,     // LED GPIO, optional to provide visual effects

        -1, //GPIO_PIN_BATTERY,  Battery monitoring GPIO. When it is lower than particular level, it will give notification to the application

        -1,  //GPIO_PIN_BUZZER Buzzer GPIO, optional to provide audio effects

        -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 // other GPIOs are not used

    },

    /*.gpio_flag =*/

    {

        GPIO_SETTINGS_WP,

        GPIO_SETTINGS_BUTTON,

        GPIO_SETTINGS_LED,

        0,            //GPIO_SETTINGS_BATTERY,

        0,            //GPIO_SETTINGS_BUZZER,

        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

    }

};

Here is my changed code with all GPIO pins disabled:

const BLE_PROFILE_GPIO_CFG my_APP_gpio_cfg =

{

    /*.gpio_pin =*/

    {

        -1,//GPIO_PIN_WP,      // This need to be used to enable/disable NVRAM write protect

        -1,//GPIO_PIN_BUTTON,  // Button GPIO is configured to trigger either direction of interrupt

        -1,//GPIO_PIN_LED,     // LED GPIO, optional to provide visual effects

        -1, //GPIO_PIN_BATTERY,  Battery monitoring GPIO. When it is lower than particular level, it will give notification to the application

        -1,  //GPIO_PIN_BUZZER Buzzer GPIO, optional to provide audio effects

        -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 // other GPIOs are not used

    },

    /*.gpio_flag =*/

    {

        0,//GPIO_SETTINGS_WP,

        0,//GPIO_SETTINGS_BUTTON,

        0,//GPIO_SETTINGS_LED,

        0,            //GPIO_SETTINGS_BATTERY,

        0,            //GPIO_SETTINGS_BUZZER,

        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

    }

};

The result is ~1.8uA (I am using FLUKE 87V Multimeter) if it is in deep sleep mode. The result is the same as yours.

BUT, when I tested in sleep mode where it MUST keep connection with my iPad, its average current is ~0.70mA. BCM20736A1.cgs is set for low power configuration.

ENTRY "Sleep Mode Configuration"

{

    "Sleep mode" = "HIDD"

    "Sleep enable" = 1

}

My questions are:

1) The average current is ~0.70mA with your demo (but with connection ON). It is still too large for any BLE application. Although connection interval parameters are set with bleprofile_SendConnParamUpdateReq(80, 400, 0, 700);

2) To reduce power, I also changed connection interval parameters to bleprofile_SendConnParamUpdateReq(620, 640, 0, 500);

but I still get around 0.70mA , no improvement in power consumption from your demo code!!!

But with hello sensor demo from SDK, its current is reduced to ~0.20 mA. Still large for BLE application, but at least there is an improvement. Can you explain why?

3) Your document said that sleep current consumption is roughly 24uA for the BCM20732, is it the same as BCM20736S?.

Also, Is there any demonstration to show that BCM20736S ~24uA with connection interval parameters (620, 640, 0, 500);

Thank you for your help

Regards

hnhu

In addition to embeddedmasters, j.t may be able to help with this as well.

0 Likes
Anonymous
Not applicable

embeddedmasters, j.t

Thankyou mwf_mmfae,

Hello embeddedmasters, j.t.

Could you please help answer the above 3 questions highlighted in red text? This is a show-stopper issue for us as we expected power consumption in sleep mode while connection is active should be much lower.

Thanks

Anonymous
Not applicable

Hello Hoang,

  I can take some time to measure this tomorrow with your Connection Settings.  Please keep in mind all of the measurements were taken with a EMRF-20732S/20736S-BOB(Breakout Boards) which have an ultra low power regulator and is well below 1uA Iq.  There will be a substantial difference in your IDLE/SLEEP current depending on the DC/DC regulator that is used which is directly correlated to the DC/DC Iq.  I am assuming you are taking your measurements on a TAG3 board, correct?  The item that is different from what you are doing than from what I did was my measurements were taken during Advertising not while the device was connected to a client. 

Regards,

Frank

Anonymous
Not applicable

Hi Frank,

Thanks for your reply!

We measured on our custom board (not TAG3) which is very simple: there is no DC/DC regulator, the 3V 40mAHr coincell battery feeds WICED BCM20736S directly.

In our application, 98% of the time, WICED is in connected mode (with not much activitity) with an iPAD. Specifically, the connection interval parameters = (620, 640, 0, 500); we expect WICED firmware to automatically go to SLEEP mode, when necessary, for best power savings. As reported earlier, in the SDK's Hello Sensor example, we did see some power saving (ie current is reduced from ~0.7mA to ~0.21mA using the above connection interval parameters) but we feel this is not enough.  (This is based on our previous experience using TI CC2541 BLE chip for the same design/application: it consumes only 0.06 mA with connection interval parameters (620, 640, 0, 500) )

Is there a way to verify whether the FW, in connection mode, has automatically put the chip in the most optimal sleep state when necessary, with the above connection interval setting?  We hope this current level is in the order of 19uA-24uA (rather than 210uA) as shown in WICED datasheet

Thanks

Hoang

santol j.t arvinds

Have you tried to force the device into SLEEP mode?

This thread explains how to place the part in sleep mode and verify the request was honored: How to enter HIDOFF? How to detect if the request is not honored?

Anonymous
Not applicable

Hello Hoan,

  I have not had a chance to measure the Connected Idle current yet but wanted to get a response to you.  The biggest situation you have where you are dealing with is to optimize battery savings/minimize Idd you really need to operate the BCM2073xS at as low of a voltage as possible.  You have to keep in mind there is an internal LDO that take the voltage you are supplying to the device and drops it down to 1.2V internally for the Radio and Mac portions of the SOC.  You need to put a DC/DC or at least a LDO in place between the Coin Cell and the BCM2073xS and drop the voltage to as low as you can.  For best results I would suggest at least 1.8V.  You can actually operate the BCM2073xS down to around 1.6V but most people's system logic does not work well at that voltage.  A couple of other things you can do is to Disable the Debug Output from the HCI Tx line.

  For validating whether or not the device is in IDLE mode the easiest way is to use something to look at the Power Profile.  I believe there may be an API function to determine whether the device is actually in the IDLE/SLEEP mode but I am not sure what this is off the top of my head.

Regards,

Frank

Anonymous
Not applicable

Hi Frank,

Thanks for your reply !

- Because our custom board does not use an external DC/DC  (such as TPS62740) , from your suggestions, we tried these 2 followings steps:

1) Instead of 3V coin-cell battery feeding WICED chip, we use an external power supply and vary its voltage from 1.6V to 1.8V directly to the chip.

2) Disable the Debug Output from the HCI Tx line by setting bleapp_trace_enable = 0 and changing the following in sparinit.c  :

(BLE_APP_ENABLE_TRACING_ON_HCI_UART() is replaced by  LE_APP_DISABLE_TRACING() );

But NEITHER of these 2 experiments help reduce the power consumption !

Any other ideas would be much appreciated !  We need the IDLE current (which I think you defined as the optimally low current level the firmware automatically puts the chip in, while connection is active) to be as low as possible (around 20uA to 50 uA. Currently it is around 200uA which will drain the coin cell battery too quickly)

Thanks

Hoang

Anonymous
Not applicable

Thanks mwf_mmfae on the link about how to force the chip into DEEP SLEEP mode and how to verify the request was honored. I also found the following link having lots of good info about DEEP SLEEP (no connection), as well as SLEEP(while "connection" is active)

Sleep Deep_Sleep Explanation and Techniques

But, in none of these links (your link and the above link), i couldn't find any info on power consumption (or current level) while "connection" is active. I realize this current depends on "connection interval" setting  which allows the firmware to automatically put the chip in SLEEP mode at appropriate time.

  -Do you have some typical values of the current level for some "connection interval" settings?

  -Also, could you confirm, while connection is active, the firmware automatically selects when to go into SLEEP mode (depending on the chosen "connection interval") for best power savings?  (ie the programmers cannot and don't need to know when to force the chip into SLEEP mode)

Thanks

Hoang

I'll see if the applications group has done any measurements with the device in connected mode.

j.t

Anonymous
Not applicable

Hello,

Thanks for your reply with power consumption behavior-Part1 for the Advertising mode. But, again, what we need is Part2 (current consumption in the Connected IDLE mode, which should be a function of "Connection Interval" setting; Please see the 2 specs below from CSR and TI BLE chips/datasheets): for these 2 chips, the current level is about 14uA to 23.9uA, whereas from our earlier report, BCM20737's measured currentlevel is 10X larger (about 210 uA) even though we have lowered the input voltage to BCM20737s to 1.8V, per Frank's recommendation. We are not sure if BCM20737S has automatically entered the Connected IDLE mode (based on the given "Connection Interval" setting) to achieve lowest current consumption. How do we check this actually happened and to get the current level to reduce from 210 uA to that of CSR or TI chips ? (10X smaller)

Thanks

Hoang

#####################current consumption specs of CSR1010 in Connected Idle vs Connected Active mode ####

Detail on CSR1010:

Table 8.1: Current Consumption Values of Section 8.Current Consumption page 41

"

Current Consumption of Connected Idle (Connection with the GATT Client device) is 14 μA at conditions:

     Minimum connection interval: 500 ms

     Maximum connection interval: 500 ms

     Slave latency: 4 intervals

     Measurement time duration: 60 s

Current Consumption of Connected active (Connection with the GATT Client device,Send a battery notification every 5 s) is 21 μA at conditions:

    Minimum connection interval: 500 ms

    Maximum connection interval: 500 ms

    Slave latency: 4 intervals

    Measurement time duration: 60 s

##########Current consumption of TI CC254x in connected mode( with 1sec connection interval) ####

Go to Page 18, the paragraph is above 5.6 Using Excel Spreadsheet for Calculations: 

It shown that the average current is 23.9 uA for 1 second connection interval and zero slave latency.

I will ask the developers how to determine whether or not the part has entered into connected idle mode.

Unfortunately, we do not have any internal power measurements taken with the chip in a connected state.

I wanted to check in and let you know that we are still escalating this internally with the Business Unit and trying to get some cycles from the development team to investigate.  Thanks for your patience.

I do know that internally we have struggled to get accurate current consumption readings from the TAG3 because of ground plane issues.  In addition, the board does not use a DC-DC, so any measured value would be at least 50% lower than what's listed in the datasheet (the datasheet has a note to this effect as well).

arvinds

j.t

embeddedmasters

andrew997

Anonymous
Not applicable

Just an unsolicited comment.   If you are using linear regulators, current consumption won't go down if the input voltage to the regulator changes.  The amount of power (in watts) consumed will drop but the current remains the same.   A linear regulator burns whatever excess voltage as heat in the regulator and can be quite inefficient.

The only way to truly reduce battery current is to use a switching regulator.  You have to be careful here because this can introduce switching noise on your power supply and this can play all kinds of evil games with radios or other linear circuits.  With current consumption in the 1-50 microamp range, switching regulators will probably still burn more power than the circuit it powers.

Anonymous
Not applicable

Sure, an LDO burns the voltage difference. But if current goes down on load, the burning heat goes gown as well.

Any optimization on load (current consumption) will help for longer battery capacity available.

Sure, SPS is more efficient but I would assume a good design and using frequencies not as harmonics of other clocks, oscillators, RF ... can help. My five cents: SPS needs often inductors which result in higher BOM and more complicated PCB (LDO can be inside and very small).

I think, he has spent his brain power to improve by better core sleep mode states. It sounds valuable and reasonable for me as (or do you expect we can change the silicon and the system design during this Hackathon?    )

I appreciate his great achievement.

Anonymous
Not applicable

FYI

http://www.aislelabs.com/reports/beacon-guide/#chipsetstried

At the center and further down the link, there are 3 or 4 tables showing battery life as a function of Tx power and "Connnection Interval". This is what I meant by power consumption in "Connected IDLE" mode in my problem report: WICED SMART datasheet has none of this, and worse, when I tried to measure it, it is much poorer than TI and Nordic chips.  Maybe this lack on info is why WICED is not used in any of these 16 leading vendors of iBeacons .  (Note: BlueGiga and Gimbal in this link also use TI BLE chips but they write their own low-level firmware for further optimization)

Anonymous
Not applicable

This sounds really cool.

Let me expand the day to 25 hours so that I can try it as well.