Boron Stuck Breathing Green

Hi - I have a Boron running on my test bed that started breathing green for no reason last night. I have the device in trace mode and connected to the computer via USB. There are no trace logs being created by the device, nothing. The computer rebooted for patch the other day and serial trace was not captured at the moment it stopped responding. I have days of previous logs that show several reconnect events. Device has a charged battery connected. Console shows the device is offline.

Why would a device be in green breath mode and not produce any trace info? I have snapshots of the console for 15 days it's been running and a dump of the trace i did capture, anything I can look for in the trace that might give a hit of why it appears crashed ?

If the recently flashed firmware required a Device OS update, and one or more components have not yet been upgraded, presumably because the device cannot get online, it would be blinking green with no logs. The reason is that until the unmet dependency is resolved, the user firmware cannot run and the device is trying to go into safe mode, and safe mode does not log to USB serial.

If you are at the device with a computer, you could try flashing the Web device doctor which will flash not only the troubleshooting firmware, but also Device OS and its dependencies.

Also make sure your SIM card didn't get deactivated.


The firmware has been stable on the device and not updated for several weeks. I checked the portal and the SIM card shows as active. If I reboot the device and it recovers normally I assume that would confirm the firmware is complete with no outstanding dependencies? Any other suggestions before I hit reboot?

For the record I hit the reset button and the device connected to cellular and booted the firmware as expected and is working correctly. Any thoughts on why this happened would be welcome, it does not leave me with a great deal of comfort deploying these devices not having an reasonable answer (and solution) for this event.


a reasonable solution could be to code defensively against this.
You could add to your firmware a mechanism that if there is no cloud connectivity, the device tries to recover itself from it. Example: after 15 minutes of disconnect, reset the device.


Good suggestion, it's already in the firmware. Problem is when the device hits this state the firmware code is no longer running. So the cloud check code never runs, it's like the device is dead and requires a hard boot to recover.

That risk can be mitigated with a watchdog:

Thank you for this solution, I was not aware of the watchdog option. I have implemented the firmware and am testing it now. This looks like a great solution so long as the watchdog is running even when the device is trying a cellular connection. I had yet another test machine go offline after a month today, rapid green flash this time. For those reading the thread, here is the link to the details on how to implement the hardware watchdog: Watchdog - Hardware | Reference | Particle

1 Like