Boron LTE - never get out of Flash Green mode

Is there a definitive solution (always works) to the “Boron stuck in Flashing Green” when attempting connect?

OS 1.5.2. Devices are running in an area where cellular strength is around 40%

The model I am using goes like this:

  1. In normal operation, the devices are connect to the cloud 7/24.
    Data to publish is buffered and sent upstream while “Particle.connected()” returns true

  2. When the “Particle.disconnected()” returns true

    A. Uses “Particle.disconnect” followed by “Cellular.off()” to turn the modem off

    B. Wait 5 minutes

    C. Uses Cellular.on() following to Particle.connect() to attempt a re-connect

    D. Wait 10 minutes for “Particle.connected()” returns true

    E. If the “Particle.connected()” does returns true in 10 minutes

    F. Return to step A

  3. In 99.9% of the time, this model works as one might expect - after one or more attempts the “Particle.connected()” returns true

  4. In 0.1% of the time, this model fails and the Boron never come out of the “flashing Green” state.

  5. Pressing the “Reset Button” and restarting the device always works.

  6. During the connection recover process - step 2, the application continue to run and buffer data to be published when the connection is re-established.

Questions:

A. Is there a better model to use?

B. Is the a Cellular.command() sequence the resets the cellular modem to the same state as pressing the “reset button” does.

All suggestion welcome. Thank you

Although you might not be wanting a hardware solution, I’ve been very happy with the implementation of the AB1805 watchdog per this application note:

It includes external RTC, hardware watchdog to reset the device if something hangs as well as a “deep power down” that pulls the EN pin and RST pin low for 30 seconds effectively resetting the device and modem if it’s unable to connect after 10 minutes (or whatever duration of time you specify). Not sure if you are just prototyping with a breadboard, using other featherwings or have your own PCB. If it’s your own PCB, I’d recommend trying to include it. I’ve yet to have a device not self recover.

1 Like

@ jgskarda Thank you for the suggestion/proposal. I am attempting to get a solution that does not require a hardware reset. If I have to go down the hardware reset road, I will need to store the data in a file systems so it is not lost across resets. In my applications, the device actually goes outside cell range from time to time.

@Jibeset tried System.reset(RESET_NO_WAIT); ?