we got another problem with the p2 (with deviceos 5.4.1) and have seen it a couple times now: stuck at breathing magenta. it is not doing anything (no vitals published, no logging) but the particle console still thinks it is online (and shows the cyan dot), it is pingable from the console and the (hw) watchdog is not kicking in to restart.
last bit of logging below
anyone any idea what is going on? (and how to avoid this!)
0001114518 [app] INFO: Telegram stats: 1109 0 0 778 778 10 46
0001114519 [app] INFO: State: 'wifi cloud connected', reconnects: 1
0001114521 [app] INFO: last read: a=0.217014, 1.008330, 1.225919
0001124519 [app] INFO: Telegram stats: 1119 0 0 778 778 10 46
0001124520 [app] INFO: State: 'wifi cloud connected', reconnects: 1
0001124522 [app] INFO: last read: a=0.217108, 1.006565, 1.227532
0001134520 [app] INFO: Telegram stats: 1129 0 0 778 778 10 46
0001134522 [app] INFO: State: 'wifi cloud connected', reconnects: 1
0001134523 [app] INFO: last read: a=0.217108, 0.962801, 1.227532
0001136852 [comm.coap] TRACE: Sending CoAP message
0001136855 [comm.coap] TRACE: CON 0.00 size=4 token= id=20248
0001136968 [comm.coap] TRACE: Received CoAP message
0001136973 [comm.coap] TRACE: ACK 0.00 size=4 token= id=20248
0001141670 [comm.coap] TRACE: Sending CoAP message
0001141675 [comm.coap] TRACE: CON POST /d?\x04 size=155 token=9c id=20249
0001141790 [comm.coap] TRACE: Received CoAP message
0001141793 [comm.coap] TRACE: ACK 0.00 size=5 token=9c id=20249
0001144521 [app] INFO: Telegram stats: 1139 0 0 778 778 10 46
0001144523 [app] INFO: State: 'wifi cloud connected', reconnects: 1
0001144524 [app] INFO: last read: a=0.217297, 1.009215, 1.228070
0001151825 [hal] INFO: WiFi is already on
0001154522 [app] INFO: Telegram stats: 1149 0 0 778 778 10 46
0001154524 [app] INFO: State: 'wifi cloud connected', reconnects: 1
0001154525 [app] INFO: last read: a=0.217202, 0.967884, 1.226994
Breathing magenta is called Safe Mode and in that mode it is expected that the device connected to the Particle cloud but wouldn't do anything with respect to your code as in that mode your code is prevented from running by design.
There are several reasons why a device might enter Safe Mode.
One of which an OTA update (intentionally or "unintentionally" via a Product firmware rollout or rollback). This may also happen multiple times when a application update implicitly requires a Device OS update too.
Another possible reason (at least for former generations) was when the Device OS detects multiple SOS crashes within a short period. In such a case Device OS suspects a logic problem with the application code and hence puts the device in a state where it can be reflashed OTA.
You could run a
particle serial inspect (in Listening Mode / blinking blue) to see whether there are any red flags.
unfortunately the device is in the field and i am not able to connect usb to query it
there was no intention to ota update the device. it is marked as development device. it was flashed a day before from visual studio device. the last lines of (remote) logging also do not suggest ota update/flashing is imminent. also there were no multiple crashes/restarts since flashing. but...
what we do have at startup is in case of panic it will explicitly enter safemode (and since not yet connected no logging) - that must be the cause
(now why do we get the panic...)
btw: is there a way to get a device out of safemode remotely?
You can reflash it OTA with the same version of your firmware (or any other code you may want to debug the issue).
is this your own HW watchdog? if so, I would look into why is not kicking in and resseting the device. Or maybe it is, but a panic happens right after and then it goes into safe mode again, as per your code.
p2 has a hw watchdog - that is what we are using. i removed the System.enterSafemode() in our "log reset reason" function. next time maybe we see what is going on
The MCU watchdog on the P2 and Gen 3 is disabled in DFU and safe mode, because it could take a while to update the device firmware.