Findings sleep modes

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

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.

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.

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