Electron OS 1.0.1 no cloud connection after deep sleep

electron
Tags: #<Tag:0x00007f1ca2516330>

#1

Hello,

I have an electron that is having issues with connecting to the cloud after a deep sleep cycle.

At initial power connection the device turns on and connects to the cloud as expected and successfully publishes. On the next wake event the device begins to flash green and never connects to the cloud. It flashes green for a while then a slow blue flash happens for about 2 seconds then it turns off. If I hit reset it usually works like an initial power connection and connects to the cloud and publishes.

Here is the code I am running:

int minutesBetweenWake = 1;// how long to wait between wake times
CellularSignal sig;

void setup() {
    //for debug opens up the usb serial port
    Serial.begin(9600);
}

void loop() {

	sig = Cellular.RSSI();
	Serial.println("RSSI    : " + sig.rssi);
	Serial.println("Quality : " + sig.qual);
	Serial.println("Combined: " + String(sig)); // Complete structure also printable
    
    //Publishes
    //wait 1 second
    delay(1000);
    //publish combined reading and status
    Particle.publish("sig_strength", String(sig.rssi));
	Particle.publish("sig_quality", String(sig.qual));
    //wait 1 second
    delay(1000);

    // Put the device to sleep for a given period. Code will execute from the beginning when it wakes
    System.sleep(SLEEP_MODE_DEEP, (60*minutesBetweenWake));
}

I was running fine in a previous OS version of 0.8.0-rc11 . I upgraded the electron from 0.8.0-rc11 to OS 1.0.1 and now I am having issues. Code is also compiled for OS 1.0.1.

My electron uBlox module model is SARA-U260.

This issue is very similar to another users reported issue from March of 2018

Any help resolving this issue would be greatly appreciated!


Electron - Advice needed on good practice for managing connection in manual mode
#2

Welcome to the forums!

I ran your code on a 1.0.1 Electron E260 and it behaves as expected. It takes about fifteen seconds to connect after waking.


#3

Thanks for the quick test and response. So I am not sure what is causing my issue. I wonder if the process of converting from OS version of 0.8.0-rc11 to v1.0.1 caused some issues. I did the upgrade over the air. Just curious how did you apply OS v1.0.1 to the electron you were testing with.

I have considered reloading the OS manually to see if that fixes the issue.


#4

I have manually reloaded the OS over USB in DFU mode but this did not resolve the issue. Still experiencing the same thing. The cloud connection will work on first power up or after I press the reset switch but will not work after waking up from a deep sleep period. It just flashes green until it times out after about 5 minutes.

I have decent cell signal as you can see in the diagnostic info below that get gets posted after a reset:
{“device”:{“power”:{“battery”:{“charge”:97.11,“state”:“charged”},“source”:“USB host”},“system”:{“uptime”:778,“memory”:{“total”:111616,“used”:27624}},“network”:{“connection”:{“status”:4,“error”:-1,“disconnects”:0,“attempts”:3,“disconnect”:0},“signal”:{“rssi”:-81,“strength”:41.66,“quality”:87.75,“qualityv”:-3,“at”:4,“strengthv”:-81}},“cloud”:{“connection”:{“status”:1,“error”:0,“attempts”:1,“disconnect”:0},“disconnects”:0,“publish”:{“rate_limited”:0},“coap”:{“unack”:0}}},“service”:{“device”:{“status”:“ok”},“coap”:{“round_trip”:1085},“cloud”:{“uptime”:1,“publish”:{“sent”:1}}}}


#5

I have used the STM32 ST-LINK Utility to roll back the OS to 0.8.0rc-11 and it is working correctly. I used the same utility to reflash the electron OS to 1.0.1 and the device showed the same issues as before. On OS 1.0.1 the device will not connect to the cloud after a deep sleep cycle.

Not sure what else I can do to get this device working correctly on OS1.0.1. Any suggestions?


#6

We had an internal discussion about something similar last week. One comment was this:

If updating to 1.0.x causes a users app to start hard faulting, the code probably needs to be updated to work with some of the changes that have been introduced. I do not have complete context here, but I know two things that can cause a hard fault:

  1. Initializing things before the system has come up fully (at least in threaded mode)
  2. Code inside of interrupts that will cause memory to be allocated (such as some String operations)

Do either one of those apply to your code?


#7

So we are not working on a separate thread other than the normal processing thread so for scenario one I don’t think that would apply. We are using the default setup and loop to initialize things as you can see in the code I provided.

For scenario two we are not wired into any interrupts that I am aware of (again looking at the code I provided) it is a pretty simple set of operations.

Where can I find a list of the changes that have been introduced that have been predicted to cause hard faults in old code?


#8

We are also experiencing the same issue. We upgraded a few of our devices to 1.0.0 and had to immediately roll back due to the devices repeatedly becoming unresponsive and needing a physical reset. The same code had 0 issues on 0.7.0.