Findings sleep modes

I was under the assumption that Standby power draw from the STM32 off the 3V3 rail is ~3.2uA, and it would get that through the diode from VBAT backup battery. Therefore, who cares if you can’t just power RTC or just power the STM32… power them both at something < 10uA and your backup battery doesn’t have to be a coin cell… could be a nice A123 3.0V Lithium.

The shutdown pin would have to be “SHUTDOWN” when tri-stated, and “POWERED UP” when pulled low.

How does the core ever power up then when you don’t have a backup battery installed? I suppose you’d need a cap on the shutdown pin that held it low low enough for the STM32 to power up and take over.

During the wake-up phase, the diode/backup battery would have to support a short burst of current before the 3.3V LDO is enabled. If you say this is 50mA, I’ll take your word on it, but the diode is still so tiny at even 100mA.

FYI: I’m just throwing these out as suggestions… I haven’t done any digging in the STM32F103 manual to verify any of this. Just seems like a good way to me… or at least on the right path to a good way!

2 Likes

Anyone tried the regular sleep mode yet? Deep sleep works fine, my Spark Core connects back to my Wi-Fi in an instant, but regular sleep mode fails because my Core suddenly hasn’t got any code anymore. Or something like that.

This is what happens after sleep:

  1. Green flashing for the amount of seconds I ask it to sleep

  2. Green lit

  3. Cyan lit

  4. Green flashing

  5. Cyan flashing

  6. Cyan breathing

  7. Empty sketch when calling the core’s URL. No functions or variables available. Returns:

    {
    “id”: “ID”,
    “name”: “Core”,
    “variables”: {},
    “functions”: []
    }

A reset enables my sketch again. Other times I get a 1 second red flash, but not often.

1 Like

I'm getting opposite results.

In Deep Sleep Mode, my core will wake up (blinking cyan) and go back to sleep repeatedly

In Sleep Mode, the core blinks green during the sleep time & executes the loop() at the same time. Once it restarts and goes into breathing cyan, no code runs

char LED = D7;

void setup() {
Spark.sleep(SLEEP_MODE_DEEP,5);
Spark.sleep(5);
pinMode(LED, OUTPUT);
}

void loop() {
digitalWrite(LED, HIGH);
delay(500);
digitalWrite(LED, LOW);
delay(500);
}

@kennethlimcp adding this to a pre-existing bug on our backlog:

I made a quick run through the datasheets and came up with these current draws summing ~150 uA as the very minimum with everything sleeping and/or deselected.

120.0 uA - voltage regulator
3.2 uA - microprocessor
5.0 uA - transciever
20.0 uA - flash memory

As previously requested @RWB this LDO can take up to 16V in and has an enable as well as an eco mode that can get the quiescent current down to 6 uA typ for a sleep condition:

I’d have to go back through the worst case power requriements to be sure 300mA is enough though.

300ma is probably pushing it if you want to do more that just be connected to the Cloud, i.e., attach loads to your I/O.

Has else anyone tried entering a low-power mode with external circuitry holding the RST line low? For hours.
Across the pushbutton?
I measure about 2.2 ma in reset which is a lot but I see the User LED on weakly. Has anyone unsoldered that LED and measured board current in RST? My soldering skills are such that the board would never work again if I attempted that.
And I haven’t done an extended analysis to see what else is going on with an extended external reset.
I would vote, as suggested above, for the 5 pin MCP1825 in a board rev. but then I don’t have to place and route it either.

Resetting the core doesn’t put it in low-power mode which explains the 2.2mA.

It’s relatively low compared to normal usage but well if you compare to sleep mode then it’s a diffierent story.

External reset is like pressing the on-board reset button which restarts the entire :spark: core as though you just powered it on.

I would think holding the STM32 in reset should make it consume less power than when it’s ON and a low frequency oscillator is running. However, holding RST low will pull 330uA through the 10k ohm pull up resistor that’s on the RST input, so right there you are killing your power savings.

Best bet would be to put it to sleep and try your current measurements then.

“Putting it to sleep” is a software thing, right? And is has a time duration–I think I read that? I guess to hold up the RAM.
I hoped my external HW circuit could run the entire power show. And uA is OK but not ma.
So the Spark Core would issue the sleep SW command, I would detect that and then hold the reset low with my circuit. And hopefully that User LED stays off while RST.
I think it will be easier to get an external 5 pin MCP1825 in series with Vin–for my case.
Thanks. I was just wondering if someone had tried this.

Yes I think you want the deep sleep function here: http://docs.spark.io/#/firmware/cloud-functions-sleep and the current should be somewhere around 120uA because the 3.3 regulator doesn’t shutdown.

If you have your own low power circuit to manage things, you could just power off the core completely for 0uA from the Core… and whatever your circuit consumes. You may or may not need to save the state of some of your variables first… and depending on your application there are many ways to do this.

Without knowing your application, I would think it would be easiest to manage everything with the Core’s deep sleep function.

Thanks again for the prompt info.
I don’t need to save state so I’ll do the power-off option. The external circuit is in charge; Spark Core is a pipe. But it does the IP stuff and all. The 'ORing" of the RST button was the cheap solution.
p.s. I see now that “sleep” has a specific meaning. I should have started my own topic.

Hey guys,

I have been doing also a little testing of the sleep modes and I got some findings:
-Do not buy the Innova 3320 multitester…I kept getting out of range under any sleep mode!
-On the deep sleep mode, I got different reading than @nika​8991 . I was getting under 1ma which for mine purpose it is great!!
-On the sleep mode, I’m getting 95ma, which is far from the 35ma. Any ideas of why? And yes, my core code stop running in this mode.

Thanks!

@manuelmasri does your core run the user code after deep sleep mode? I didn’t managed that.

What stuff is connected to the core? 95mA is kinda high in some way for sleep and would be nice to help you find out the cause

Yeap, it keeps running my code after the deep sleep mode without any problem, some times I get a red light for a little bit while restarting but nothing happens. I have connected a step motor with a ULN2003AN chip. I need to test the current again without it.

@manuelmasri can you share the code on how to go into deep_sleep_mode and where?

I would like to verify it working as I had a different result the other time!

Would be helpful to catch the bug sooner :slight_smile:

Sure, I just uploaded in here: http://pastebin.com/UMj0EEDC

Basically its the library created by the amazing @BDub that is called by a function.

I hope this works…

1 Like

@manuelmasri i see why yours didn’t end up in a lock up.

From my observation, resuming from deep sleep seems to be running the entire user code again.

I used a flag to control the sleep() to only trigger once but it kept doing it over and over again.

Let me check further.

I haven’t had the time to check how much my Spark Core uses when in deep sleep mode, but I noticed the attached moisture sensor doesn’t turn off. It’s linked to the filtered 3.3V output, so I guess it just keeps powering it, even though the Core is in deep sleep. Can anyone confirm? I’d like it to completely shut everything off, so nothing is powered besides the Core.

You would need something like a transistor controlled by a IO pin that will turn off when the Core goes to sleep mode.

1 Like