/spark/status/safe-mode data meaning

I’ve got some Argons at a remote site that I deployed to, updating from 1.5.2 to 2.0.1. After the deployment, one came back online but two seem to be stuck in safe mode. I get this big readout from the spark/status/safe-mode event. What can I learn from all this data? Here’s an example:

{
    "p":12
    "m":[
        0:{
            "s":49152
            "l":"m"
            "vc":30
            "vv":30
            "f":"b"
            "n":"0"
            "v":1005
            "d":[]
        }
        1:{
            "s":671744
            "l":"m"
            "vc":30
            "vv":30
            "f":"s"
            "n":"1"
            "v":1512
            "d":[
                0:{
                    "f":"b"
                    "n":"0"
                    "v":501
                    "_":""
                }
                1:{
                    "f":"a"
                    "n":"0"
                    "v":202
                    "_":""
                }
            ]
        }
        2:{
            "s":131072
            "l":"m"
            "vc":30
            "vv":26
            "u":"21141FA36D96EFFA46E75348CF36CAE64B3623629089DE111DCCE191C56D9580"
            "f":"u"
            "n":"1"
            "v":6
            "d":[
                0:{
                    "f":"s"
                    "n":"1"
                    "v":2011
                    "_":""
                }
            ]
        }
        3:{
            "s":1536000
            "l":"m"
            "vc":30
            "vv":30
            "f":"c"
            "n":"0"
            "v":5
            "d":[]
        }
        4:{
            "s":192512
            "l":"m"
            "vc":30
            "vv":30
            "f":"a"
            "n":"0"
            "v":202
            "d":[]
        }
    ]
}

I’ve worked a bit with this structure. It’s basically telling you which modules (device-os parts) are programmed into memory on the device. The “v” field is the internal version number for the OS. For example, 110 maps to device os 0.7.0.

The “d” field is the dependency field. It tells you which parts depend on certain versions in other parts (for example, part 3 might depend on part 2 being at least version 110 or higher).
I think the “f” field is function, I.E. bootloader, system, user.
“n” is the logical order of the section, this currently only applies to system on certain platforms (everywhere else it will just be 1, but electron has 3 system parts).

Not an expert, but it looks like array index 2 is your user part, and it has a dependency on system being version 2011 (I assume this is device os LTS 2.0.1) and I think your device os is currently only 1.5.2. Could be wrong, it’s been a bit since I worked closely with what I call the “safe-mode digest”.

When our sites got stuck like this in the past (electrons) force-flashing the device os via the API would sometimes fix it. Caution, you do this at your own risk, we’ve bricked devices using this method

1 Like

This may help

Great, thanks for that both. Should have found that other post earlier. I can now see that the problem is in module 2/user part 1, where the dependencies validity has failed. The only dependency of that module is system part 1, at version 2.0.1, but I can see that system part 1 is actually at 1.5.2. What can I do from here?

Yes, it does appear that the Argon system-part1 is at 1.5.2 (1512) but your user firmware depends on 2.0.1 (2011). This should have been fixed by the safe mode healer, but for some reason was not. The easiest solution is to just flash system-part1 for 2.0.1 to the device.

Download the 2.0.1 binaries from the release site.

Then flash using the CLI:

particle flash DEVICE_NAME argon-system-part1@2.0.1.bin

Replace DEVICE_NAME with the name of your device or its device ID.

1 Like

Great, many thanks for this. My devices spend most of their time asleep, then wake up, check for updates, and then go back to sleep. Maybe what has been happening is that after the deployment, the device wakes up, the cloud starts sending the upgrade, but then the device goes to sleep before the upgrade can be completed. Does this sound likely? Is there anyway I could find out if there’s an OS update coming so I can stop the sleep? Perhaps subscribe to /spark/flash/status?