I have a device in the field we were attempting to update to start sending a CBOR array of data, collected every 15 seconds and delivered every 3 minute.
We had 55 total firmware updates and only minor changes from one to the next and never any serious compile bugs (that we fixed of course between each iteration.). However, on this last cycle, I noticed the device was cycling much quicker and then did not allow a new firmware update to go through. I was reading about boot looping and safe mode. this device - 290051000851383133363636 has restarted many more than 10 times and has not appeared to enter safe mode.
We have no idea how to get it back among the living.
Devices do not automatically go into safe mode when boot looping. Unless you manually added code to do that, it won't. If you are rebooting before a firmware update can be sent, you probably will not be able to remotely recover it.
well thats unfortunate. I have no idea what tiny change between V54 and V55 could have changed this behavior.
I was following Grok’s advice as well:
Step 5: Addressing Rebooting and OTA Issues
Given the device's reported rebooting and OTA failures:
-
Safe Mode Detection: Monitor the Events or Vitals tab for safe mode entry (e.g., "safe mode" event after ~10 reboots). The device will appear online but run no user code, enabling reliable OTA.
-
Forced OTA Retry:
-
In the device detail page, go to the Settings tab.
-
Toggle Force Updates to ON. This bypasses version checks for the next attempt.
-
Select Firmware from the left sidebar, upload your corrected binary (e.g., the non-blocking version from prior discussion), and initiate the OTA update.
-
Monitor progress in the Events tab; if it fails again, wait for safe mode and retry.
-
Remote Diagnostics Guide: For deeper troubleshooting, refer to the official documentation at docs.particle.io/reference/device-cloud/remote-diagnostics, which details vitals polling and automated health reporting.
If it’s impossible to recover this device thats currently running in Mexico, thats fine, but how do test software changes on a basically obsolete device, 1000 miles away safely? We really do want to implement sending data as a CBOR array.
Thanks,
Todd
That advice is mostly wrong.
Safe mode is automatically entered unless the user firmware is erased, the buttons pressed, entered through software, or as part of a Device OS upgrade, but never for rebooting.
Forced OTA only forces an update that was deferred because the local firmware has disabled updates. It won't help for rolling reboot.
We usually recommend deploying to a devices you have local access to before deploying to your fleet. And it is possible to add the code for rolling reboot detection with safe mode, it's just not built-in.
Hey Todd!
The times I got in trouble like you describe I added a 2 or 3 minute delay at setup() right before running any code. If the device could take some time to connect to Particle, then check also for Particle.connected() or increase that time.
This way you add a safety net for your changes while you are testing them.
If something goes wrong, you have that delay() that will allow you to reflash the device with a fix, until you nail things down.
Once everything is to you liking, you can remove this delay or you can leave it there but filter it with a check for a panic reset like System.resetReason() == RESET_REASON_PANIC.
Best,
1 Like
Can you instruct someone to set it to safe mode with the device buttons and some instructions?