Findings sleep modes

Firmware
1

Hi,

Here my findings with the sleep/deep-sleep mode, I have added the following code (based on the Firmware documenation):

else if (args =="Sleep") {
    // Put the Core to sleep for 5 seconds
    Spark.sleep(5);
    // The Core LED will flash green during sleep
}
else if (args =="Deep") {
    // Put the Core into deep sleep for 5 seconds
    Spark.sleep(SLEEP_MODE_DEEP,5);
    // The Core LED will shut off during deep sleep
}

Sleep mode:

  • The SparkCore goes in the sleep mode for 5 seconds (RGB led flashing green) but when it comes back to breathing Cyan the program does not react anymore.
  • The supply current is about 35 mA which is a little bit above what is stated in the documantation (In standard sleep mode, the Core current consumption is in the range of: 15mA to 30mA)

Deep sleep mode:

  • The SparkCore goes in the deep sleep mode for 5 seconds (RGB led off), when it comes back to breathing Cyan the program reacts as expected.
  • The supply current is about 15 mA, which is much more than stated in the documenation (In deep sleep mode, the Core current consumption is around: 3.2 Ī¼A)
3 Likes
2

About current consumption : do values stated in the documentation are about raw chips (STM32F103CB + CC3000) consumption, or do these values are about the whole spark core. I mean that the linear voltage regulator which down convert 5V to 3V3 may ā€œeatā€ too much current (especially for deep sleep mode)

3

I forgot: I donā€™t know if the 3V3 output pin may be used to provide our own 3V3 power input and bypass onboard LDO, but if itā€™s the case, you should try this and measure power consumption on this pin

4

Iā€™m waiting for some more info about actual power consumption in deep sleep mode.

In one of my projects I need the spark core to be sleeping for most of the time and wake each hour (or every few hours) for few seconds only to send report using TCP client. Would it be possible to run it on batteries then?

5

Iā€™ve posted similar findings for Sleep mode as wellā€¦ not sure if it got on any backlog. Are you sure Deep sleep mode is working fully? Does Serial and Serial1 work? I think thatā€™s what I noticed not running in my application. Itā€™s like certain peripherals are laid to rest, but not woken back upā€¦ so to speak.

6

Hi @aboudou, is not clear to me either if it is only for the chipset or for the whole SparkCore.
If I look at specifications of the onboard LDO (MCP1825S-3302E/DB) then the Input Quiescent Current is between 120 and 220 Ī¼A. So to my understanding the 3.2 Ī¼A cannot be for the whole SparkCore in the deep sleep mode.

7

Hi @BDub, you are right, the Serial interface is not working anymore after the deep sleep mode.
I am using the Serial interface only for debugging, the rest of my program seems to work as normal after the deep sleep.

8

Also good point about the LDO quiescent currentā€¦ the one they are using does not have a shutdown pin, but even if it did that would completely kill the STM32.

Perhaps there is a ā€œgotchaā€ with the 3.2uA spec, where you must power the Core with a regulated 3.3V supply directly on the 3V3 pin.

For remote sensing applications you would need a way to shut down your main regulated power source and stay powered in sleep mode from a diode isolated 3.0V Lithium Battery.

9

Just seeing this now, looks like that didnā€™t make it onto the backlog, added.

Thank you!
David

1 Like
10

Perhaps this would be a good hardware revision for the Spark Coreā€¦ add the MCP1825 with the shutdown pinā€¦ and add a solder point for the VBAT pin (RTC module power in STM32) and a Schottky Diode on-board between the VBAT pin and the 3.3V output, anode on VBAT, cathode on 3.3V. Then all you have to do is wire up a coin cell or larger 3V battery to your VBAT input solder pad. Deep sleep like a baby.

3 Likes
11

Okay, thanks for the tip.

1 Like
12

Mentioning @mohit so he seeā€™s that suggestion :slight_smile:

13

So Deep Sleep is working but the Serial lines are dead after you come out of deep sleep right?

Is anybody working on getting that resolved? I guess if your sketch does not require any serial communication then its not a problem. Would this bug also affect I2C communication?

14

bDubā€™s suggestion about the buck regulator hardware upgrade is a good one. Being able to deep sleep at 3.2uA and have the RTC working also would be a move in the right direction.

1 Like
15

I have not done extensive Sleep mode testing, I just found it buggy and moved on as I didnā€™t actually need to use it myself at the time. Seems like someone should really take a look at it, but right now I have my hands full with too many projects! :smile:

16

I believe this is still a bug, and is still pending a fix, hopefully weā€™ll be able to get to it in the next sprint or so.

Thanks,
David

17

+1 on bringing out the VBAT pin. I would rather have VBAT on Pin 4 instead of the 2nd ground pin. But leave the diode off, the battery circuit should be up to the user on an external circuit. Its Ok to leave VBAT floating when no battery is present.

Having a regulator with shutdown pin doesnā€™t help unless the shutdown pin is brought off the board. If you donā€™t want to use the onboard regulator, donā€™t power the core with the RAW voltage input, instead regulate offboard and supply the +3.3V pin.

1 Like
18

Shutdown pin is meant for the Spark Core to Shutdown the 3.3V Regulator. When it does, the VBAT pin will be the only thing powering the RTC and Spark Core ( through the diode :slight_smile: ) The diode can be tiny, since it only needs to handle uA of current. There should hardly be any forward voltage drop. When the 3.3V comes back, the diode is reverse biased and the Spark Core gets power from the 3.3V LDO. The RTC would still be powered from the VBAT (I think), but it should technically last for freaking ever.

Having to regulate your own 3.3V supply doesnā€™t solve the low power problem, because now how are you going to shutdown your own current hungry LDO when you put the Spark Core to sleep? Use up a digital output? Think about a way to make that workā€¦ I canā€™t, unless you hook up a backup battery to VBAT, with a diode to 3V3. I donā€™t see any good reason to offload all that stuff on the user, when you just need to bring out 1 pin (VBAT) and add one tiny diode, and use the onboard 3.3V LDO (which I wish was rated higher than 6V input - at least 9V so we can have a two cell Lipo powering things).

I kind of like having a GND connection on both sides for prototyping, but VBAT would be more usefulā€¦ especially if you had a Battery Backpack shield that you could just plug right in.

4 Likes
19

I agree with BDub on his recommendations.

It certinaly would be great to have a LDO that could handle input voltages up to 16v so we could power the chip from 12v batteries even when they are at a fully charged state.

Making the RTC functional is going to be a great thing also considering for the price of the Core your getting a whole boat load of value once all the bugs are worked out.

20

If you include the diode from VBAT to +3.3V there becomes no way to power only the backup power domain with the battery connected. You will not be able to use the ā€˜Standbyā€™ power down mode to switch off the onboard regulator since when the +1.8V reg in the STM32 is powered off in Standby, all of your GPIO will tristate.

Best power save mode is then ā€˜Stopā€™ mode (with internal 1.8V core reg on) for about 25uA. If you were running only the backup domain including the RTC power consumption becomes ~1.5uA.

The VBAT->3.3V diode would need to handle close to 50mA since this could be the STM32 utilization before the regulated 3.3V was removed.