MAJOR BUG in 1.0.1-rc.1 and 1.0.1

electron
Tags: #<Tag:0x00007f1ca3072198>

#1

There is a MAJOR bug in the 1.0.1-rc.1 and 1.0.1 firmware. I have been tearing my hair out trying to figure out why the Electron will NOT reliably reconnect to the network after using ANY of the System.sleep() commands. I have tested on every version using the code below since 0.5.4 and it doesn’t show up until 1.0.1-rc.1 so I tried it on 1.0.1 and it does the same thing. I have tried multiple 3G Electrons in the EXACT same location and get the same issue.

Any version of code before 1.0.1.-rc.1:

  1. Let the Electron do something (in this case just delay and serial print then do a System.sleep().
  2. Electron does it’s thing, and goes to sleep.
  3. 30 seconds later it wakes up and connects to the network within a few seconds. Just like it’s supposed to.

Version 1.0.1-rc.1 or 1.0.1:

  1. Let the Electron do something (in this case just delay and serial print then do a System.sleep().
  2. Electron does it’s thing, and goes to sleep.
  3. 30 seconds later it wakes up and flashes green and never connects back to the network. If I power cycle it it connects within 1-2 minutes. It will sometimes connect back to the network after several minutes, but that is only about 10% of the time. I have let this run all night and only had 3 successful connections using this firmware or the 1.0.1.

Hopefully someone can figure out what’s happening.

Thanks!

void setup() {

  Serial.begin(9600);
}

void loop() {
    delay(10000);
  Serial.println("--------------");
  
    Serial.println("Going to sleep");
    delay(10000);
    
System.sleep(SLEEP_MODE_DEEP, 30);

}

#2

I don’t know if you found a bug, but you should replace both the delay(10000) with something like:
for (uint32_t ms = millis(); millis() - ms < 10000; Particle.process());
See if that helps :grinning:


#3

The delay() is just so I have time to do a particle serial monitor on the computer to time that the System.sleep() happened. delay() is a valid (though blocking) function. The issue is AFTER the sleep when the Electron wakes up. It will not run the loop until it is connected to the cloud (as it should in this mode) so the delays are just for testing.


#4

@Rftop I tried your code for both 1.0.0 and 1.0.1-rc.1 and the same issues occurred exactly the same. I rolled back to 1.0.0 and the non connection issues went away again.

Thanks for the snippet though. I will begin using it instead of delay, just for the Particle.process() addition. :wink:


#5

one thing i discovered a while back is when my electron does the extended green blinks if i tap reset a couple times in quick succession it usually reconnects. not always but about 8 out of 10 times. it’s of no use if your electron is remote but thought i’d mention it.


#6

Can you file that as a GitHub issue at github.com/particle-iot/device-os/issues ?


#7

Just a couple of questions, did the Electron cloud connect before you put it into deep sleep and are you using SYSTEM_THREAD(ENABLED); ?

I defer to @scruffr 's greater knowledge that this appears to be a bug.

IMO - you should check for Particle.connected() in setup before starting the loop and in particular before you call System.sleep(SLEEP_MODE_DEEP, 30); so that the device is in a know stable state and not in the middle of connecting. Also, the typical approach for the wait for serial setup is while(!Serial.available()) Particle.process(); immediately after Serial.begin();


#8

I have been trying to debug a simmiler problem with an electron flashing blue (listening) after waking up. I think this is related to 1.0.1 but haven’t rolled back yet to confirm.
Unfortunately it sounds like yours is a different issue but if there is one bug there could be more?


#9

Thanks for confirming my suspicions too about 1.0.1. It must have a lot of bugs, not only the one you raise. Connectivity to the network is very very unstable. We’ve been running a piece of firmware without issues in Electron for several months in 7.0 but it became too unstable once we tried it on 1.0.0 and 1.0.1.

For instance, we have a finite state machine to manage manually the connection to cloud through several states. It counts the number of cloud disconnects and after several of those (6 or more) makes a full_modem_reset (deep_sleep for 20 secs). We see the devices performing these resets too often now. Another test we made was putting the Connection_check from the electron_sample library. The effect is even worst as the connection_check resets the Electron after sensing no cloud events. Reverting to 7.0. R1.0.0 seems a bit more stable than 1.0.1 but I have not the chance to detect hard evidence to substantiate it.