Photon startup / deep sleep problem in Develop Branch

Troubleshooting
1

Hi,

I am having a problem with the photon when using the develop branch. I am using that branch, because I want to flash locally. It works pretty well, except for two things: When the develop branch is used, then it does not startup after powering up. I have to reset the board using the reset button, then it works fine.

Most probably connected: The board does not wakeup from deep sleep mode, when using that branch. It works fine when I use a board which uses the official firmware as flashed when using the web IDE.

Although the code is simple enough, here it is:

#include "application.h"

SYSTEM_MODE(MANUAL);

void setup()
{
    pinMode(7, OUTPUT);
    RGB.control(true);
    RGB.color(0, 0, 0);
    digitalWrite(7, true);
    delay(1000);
}

void loop()
{
    System.sleep(SLEEP_MODE_DEEP, 10);
}

Is this a known problem? Any workaround?

Also a question: After waking up from deep sleep it takes roughly 2-3 seconds in which the RGB led shines white, until the user program starts. This is wasteful, because at that time the LED is using energy and of course it takes time until the photon is in deep sleep again. What is done during that time? Can I somehow suppress this?

I am trying to do a battery powered device which wakes up every minute, makes a measurement, sends that through to a web server and then falls asleep again. It should run for a long time with a battery. So any overhead as described is waster.

Thanks!

2

I’m not sure but deep sleep might only be woken up using the WKP pin.

@BDub might have more information.

3

I have seen this too and am trying to resolve the issue - more datapoints would be great. Does this happen on every power up, or just on a cold start (unpowered for more than 30s.)

We could perhaps make the default brightness for the LED persistent so that you can set the brightness setting before going to deep sleep. On wakeup from deep sleep the system goes through it's startup procedure, initializing memory, peripherals, initializing WICED libraries etc.

For now, you could try to turn the LED off early (before setup is called), by adding this code to your application:

struct TurnOffLed {
    TurnOffLed() { RGB.brightness(0); }
} turnOffLed;
4

For me, it happens 100% on cold start, rarely but randomly on warm start (< 30 secs repower). Not associated with sleep function.

1 Like
5

I have a fix pushed to the develop branch which is working for me. Please test when you can and let me know! :smile:

1 Like
6

One way to speed up startup is to disable the auto DFU/firmware update functionality. This is done by commenting out

USB_USART_LineCoding_BitRate_Handler(system_lineCodingBitRateHandler);

in system/src/main.cpp (currently line 199.)

I’ve added an issue to our backlog to make this configurable at runtime, since it’s mainly a development tool for quickly loading firmware via DFU/Serial without having to touch any buttons on the device.

2 Likes
7

Works! Tested it with a couple of 60 second cold restarts. Thanks!

1 Like
8

Does seem to speed startup, but probably impossible for me to really tell. Commenting out this line has no other side effects than the elimination of buttonless flash?

9

That's correct. There should be no other affects from this change.

2 Likes
10

@mdma I am running into this issue too but recloning the develop branch and commenting out the line in main.cpp does not fix it.

Here is the simple loop I am running

#include "application.h"

SYSTEM_MODE(MANUAL);

void setup()
{
}

void loop()
{
int i = 0;

while (i < 5)
   {   //flash external led
   pinMode(D5, OUTPUT);
   digitalWrite(D5, HIGH);

   delay(500);

   pinMode(D5, INPUT);

   delay(500);
   i++;
   }
System.sleep(SLEEP_MODE_DEEP, 2);
}

What I am seeing is the device never wakes from sleep. I though this was an only occasional cold restart problem but I find now it always happens after sleep.

I know I have tested deep sleep before with success. I think the testing must have been with a compile in the cloud

My guess is some register that is used with the wdt is set incorrectly?

11

@HardWater, Did you forget #include “application.h” ? I ran your code successfully.

12

Commenting out that line is a speed up, not a fix for deep sleep.

I'll try the code example and report back.

time passes

When I run the code I find it doesn't wake up automatically. The docs indicate this should be supported, although something in the back of my mind says Deep Sleep is woken up only by the WKP pin. @satishgn will be able to affirm the expected behavior.

13

I just rebuilt the latest develop branch and flashed all the modules and now the example above is working - the photon comes out of deep sleep after 2 seconds.

1 Like
14

Hi,

thanks for the very fast response. I just tried it as well and it works like a charm, now. Great work! The photon does wake up after a power up and it also wakes from the deep sleep. And yes, it was always after a cold start, that the problem appeared. I did not really expect a cold start to only happen after 30 seconds without power. Out of curiosity: what is still running more than 20 seconds without power???

With the code to turn off the LED, it turns off a second earlier, after about 1 second instead of 2-3. That’s a good improvement.

Turning off the auto firmware update does not really help. I could not really make out a difference. But in any case, being able to turn off the auto firmware update would also be a good feature, so that you cannot reprogram by just putting in a USB cable.

Still I am suprised that the startup is relatively slow even with the manual mode. Most other MCU start up faster. So I would think that looking into that would still be worthwhile.

Thanks!

15

Do you have figures for other wifi-enabled devices for comparison?

The WiFI module is initialized also on startup. 240k of data is transferred over the internal bus. In time we may be able to optimize this so that it's done lazily on demand when the wifi module is actually required, rather than doing it eagerly.

All the code is in hal/src/photon/wlan_hal.c if you want to have a go at doing this yourself.

16

Okay, that makes sense. I compared it to non-Wifi devices, assuming that the initialization is done lazily.

I must admit that I still have some difficulty navigating the code base, especially the division into Core, Photon, and Electron is not too clear for me - yet. So the pointer to the wlan_hal.c is appreciated. I will experiment a bit myself.

Thanks again!

17

Did you rebuild/flash the system firmware? The changes are in system firmware so these modules would need updating for the change to have any affect.

18

Hi @bpr,

Actually I did have that include in there it was just left off when copying the code to this thread I just added the include for clarity.

Hum, You ran the code successfully? That’s odd I will have to try this again.

19

@mdma

Wow I just recloned then reflashed and it still does not work for me. It just never wakes from sleep.

Here’s what I did

c:
cd\spark

rmdir c:\spark\firmware /s
git clone -b develop https://github.com/spark/firmware.git

rmdir c:\spark\core-common-lib /s
git clone https://github.com/spark/core-common-lib.git

rmdir c:\spark\core-communication-lib /s
git clone https://github.com/spark/core-communication-lib.git

cd firmware\modules
make PLATFORM=photon

Then I set my Photon in DFU mode and ran this

make clean all PLATFORM=photon program-dfu

Then copied my application into my directory at user/applications/photon and set the device to DFU mode again and ran the following.

cd\spark\firmware\main
make clean all PLATFORM=photon APP=photon program-dfu

Still never exits sleep unless I press the reset button. The Photon is in a breadboard with no other circuit than power & gnd as well as the external led between D5 and gnd

This is very odd that it works for you guys and not me?

20

I see the problem. You aren’t updating the system modules with this approach. In modules, you need to run all program-dfu so the modules are flashed to the device. As is, you are only building them, not flashig them.

It’s also not necessary to have the core-common-lib and core-communication-lib repos. Please be sure to read the readme.md in the develop branch, and the build docs that are linked, particularly the section Updating system firmware.