Deep Sleep, still using 46.0ma? No wake up?

Troubleshooting
1

Hello,

I am currently running the latest sparkcore-development branch , in an attempt to get the System.sleep functionality to work correctly.

I am running the following code

void setup() {
  Serial.begin(9600);
  pinMode(A0, INPUT_PULLUP);  
}

void loop() {
  delay (1000);
  
  Serial.print("going to sleep for "); Serial.print(SleepTime); Serial.println(" sec");  
  System.sleep(SLEEP_MODE_DEEP,60);  
}

When the device goes to sleep, the LED is off and it is drawing 46.2ma in what’s supposed to be deep sleep mode, which is weird. Sometimes it will actually be in deep sleep mode and draw 0.08ma , other times it will draw 46.2ma . Never consistent though.
Also I have a switch attached to A0 and pressing the switch does not bring the device out of deep sleep.

If I change the line

System.sleep(SLEEP_MODE_DEEP,60);

to

System.sleep(A0,CHANGE,60);

Then the device will also use 40ma while sleeping in this state, but I am able to press the switch and wake up the device from sleep.

However if I change

System.sleep(A0,CHANGE,60);

to

System.sleep(A0,RISING,60);

I am no longer able to use the switch/interrupt to wake the device.

I know there have been a number of threads regarding the sleep of the device. The last thread I followed was https://github.com/spark/firmware/pull/778 , which seemed to help some people. But did not provide a solution for me.

Any ideas are welcomed! Thanks in advance!

2

Have you ever applied the bootloader update to that Core?

https://github.com/spark/firmware/blob/bootloader-patch-update/build/core-firmware.bin
[SOLVED] Not able to put my core in stop mode (it just wakes up)

3

Thanks for the reply. I am actually using a photon, would that bootloader firmware still apply?

4

I just saw this.
Nope, the bootloader patch was only meant for the Core. The Photon should work out the box (minus some issues with waking on pin interrupts, which should be solved next release).
But since you are using the develop branch you should have the fix already.

5

Is there a way I can confirm which firmware version my photon is running?

6

If you have CLI, plug the device into your computer, put it into listening mode, run particle serial inspect and post your output here (and redact the UUID line just for paranoia ;-))

7

system firmware version: 0.4.7

{
  "p": 6,
  "m": [
    {
      "s": 16384,
      "l": "m",
      "vc": 30,
      "vv": 30,
      "f": "b",
      "n": "0",
      "v": 4,
      "d": [
        
      ]
    },
    {
      "s": 262144,
      "l": "m",
      "vc": 30,
      "vv": 30,
      "f": "s",
      "n": "1",
      "v": 8,
      "d": [
        
      ]
    },
    {
      "s": 262144,
      "l": "m",
      "vc": 30,
      "vv": 30,
      "f": "s",
      "n": "2",
      "v": 8,
      "d": [
        {
          "f": "s",
          "n": "1",
          "v": 8,
          "_": ""
        }
      ]
    },

But alas SLEEP_MODE_DEEP still draws 0.40ma of current and interrupt on pin A0 does not wake up from sleep. It appears sometimes it will drop down to 0.08 ma of current in deep sleep mode , but most of the time it doesn’t.

Should I try a factory reset and reflash?

8

@elmezie, using the form System.sleep(uint16_t wakeUpPin, uint16_t edgeTriggerMode) for sleep is NOT deep sleep and will put the STM32 processor in STOP mode, using a little more current then the deep sleep mode. How/where do you measure the 0.4ma draw?

Using STOP mode differs from DEEP SLEEP mode as well in that in STOP mode the code literally stops after System.sleep() is called. Upon awaking, the code will continue from the line after the call.

With DEEP SLEEP however, upon awaking the Photon will reset, just like pressing the RESET button. As such, your code has to take these differing modes into account depending on which one you use.

9

I am measuring with a FULKE 77 Multimeter in series with the power source.

In the code I am using

System.sleep(SLEEP_MODE_DEEP,60);

Sometimes it will measure 0.08mA when sleep, most of the time it measure 45mA when sleep

10

@elmezie, the 0.08ma measurement makes sense when in deep sleep. The 45ma value is what you expect when the WiFi module is turned off but the processor is still running.

Can I suggest you drive set D7 as an OUTPUT prior to going to sleep and drive it HIGH to light the LED. The LED should turn off during deep sleep. If it does go off, then something is keeping the processor awake. Can you post your code or a minimal case version?

11

The code being used is

long SleepTime = 10;

void setup() {
  Serial.begin(9600);
  pinMode(A0, INPUT_PULLUP); 
  pinMode(D7, OUTPUT);
  
}

void loop() {
    digitalWrite(D7, HIGH);
    delay(1000);
    System.sleep(SLEEP_MODE_DEEP,30);
  
}

The first time the code ran and went to sleep the current was 0.08mA , all subsequent times it wakes up and goes back to sleep the current is at 46.5mA . There are no peripherals connected, only power.

In the two images below you can see that the LED’s are off in both images, while in sleep mode

2016-01-14 12.37.39.jpg2448×3264 1.32 MB
2016-01-14 12.37.51.jpg2448×3264 1.31 MB

12

@elmezie, can you try this code:

void setup() {
  Serial.begin(9600);
  pinMode(A0, INPUT_PULLUP); 
  pinMode(D7, OUTPUT);

  digitalWrite(D7, HIGH);
  delay(1000);
  System.sleep(SLEEP_MODE_DEEP,30);
}

void loop() {
}
13

Thanks for the reply.

I gave that code a try , and the results are the same. Although this time it never went to 0.08mA. Each sleep/wake cycle was 46mA

14

@elmezie, I’ll flag this with the Particle Team.

15

@elmezie, @mdma indicated the following:

If they can build locally, I would suggest trying develop since we’ve reworked the Sleep function considerably.

0.4.9 will be released next week.

16

Yes, I am currently running a build from the develop branch

vagrant@vagrant-ubuntu-trusty-64:~/firmware/build/target/system-part1$ git branch
* develop

Is there a way I can confirm the develop branch is indeed flashed on my device?

17

Hi @elmezie

In the photos, what is the other component on your breadboard?

Have you tried measuring without that component (i.e. no connections to the Particle device)?

18

Hey bk0 ,

The other device is a motor breakout. It is not currently connected.
The only pins i have connected are the power and gnd which are connected to VCC.

The device is being supplied 5.3v by the way.

19

To Flash,

I am doing the following :
Placing the device in safe mode and then
from particle-cli I run :

$ particle flash <deviceid> /c/photon/development-pull2/system-part1.bin
Including:
    C:/photon/development-pull2/system-part1.bin
attempting to flash firmware to your device <deviceid>
Flash device OK:  Update started

And

$ particle flash <deviceid> /c/photon/development-pull2/system-part2.bin
Including:
    C:/photon/development-pull2/system-part2.bin
attempting to flash firmware to your device <deviceid>
Flash device OK:  Update started
20

To verify the binaries have been successfully updated, you can retrieve the firmware vsersion.