Woes remote managing a boron

I’m probably doing something wrong… I have a boron sitting in front of me on the desk and I’m trying to play remote management scenarios. Some issues I’ve bumped into:

  • The battery charge in the device vitals is different from what FuelGauge.getSoC returns. I see 72% charge in the device vitals vs 62% in getSoC. The info in device vitals is up-to-date.
  • Right now my app is hung in loop() (not sure why, probably an i2c issue), the LED continues breathing so the device remains connected. How can I reset the device? I don’t see any such option in either the console or the particle-cli. (I guess I can perhaps re-upload the app.)
  • I created a cloud function that allows me to reset the device (it calls System.reset) but even though the device is connected I don’t seem to be able to successfully run functions. I assume it’s because they only run when loop returns? The docs don’t say.
  • When I send a new app to the device using the cli I see Flash device OK: Update started but I haven’t found any confirmation anywhere that it actually happened.
  • I ran diagnostics and it says “All diagnostic tests have passed, but there is 1 item that requires attention. See below for details” but there’s nothing shown below.
  • The diagnostics don’t seem to include any info about loop iterating. It would be useful to show some avg iteration time…

Thoughts on the above or pointers to what I’m missing?


How can I reset the device? I don’t see any such option in either the console or the particle-cli. (I guess I can perhaps re-upload the app.)

Nope, attempting to re-flash results in a time-out. The device responds to pings from the console and can run a diag test. At least I’m 99% sure I managed to run one. I just tried again and it failed and now I believe it’s in safe mode (magenta LED on for 4 seconds, then off for one). I then re-ran diagnostics and it reset so my app restarted. Phew, rather confusing specially if I didn’t have the device in front of me.

The device diagnostics are not fully integrated on mesh devices yet.
Without seeing your actual code it’s difficult to advise, but when you also add SYSTEM_THREAD(ENABLED) a hanging loop() shouldn’t impair the ability to call a Particle.function().
If it does, there is probably some code that’s hogging a shared resource which would prevent the system thread from doing all its jobs.

For debugging that issue you may want to add some serial logging and monitor the output.

Incorrect. Given functions:

int funcBlackHole(String in) {
    while(1) ;
    return 1234;

int funcGreyHole(String in) {
    while(1) delay(1000);
    return 1234;

int funcReset(String in) {
    return 1234;

If you call GreyHole you can thereafter call Reset and recover your device. If you call BlackHole you’re cooked. There is no way to recover. Calling Reset doesn’t work. Uploading a fresh app goes through the motions but doesn’t actually restart the app. Pings work throughout, so the device is connected, there just isn’t any way to break the application task out of the black hole.

Edit 2: a delay(1) in GreyHole is sufficient to allow for recovery.

1 Like

The next step for me was to enable the ApplicationWatchdog feature. Fortunately that works and will reset the system even if my app is in an infinite loop (BlackHole function). Great! I’m puzzled by the following statement in the docs, though:

The application watchdog requires interrupts to be active in order to function. Enabling the hardware watchdog in combination with this is recommended, so that the system resets in the event that interrupts are not firing.

Makes sense but I can’t find any way to enable the hardware watchdog… Anyone got a pointer?

One thing here

But if you feel adventerous have a look at this thread

Uhhh, I don’t think the nrf52840 has an stm32 IWDG :wink:

Doh’ missed that point :flushed: