/spark/status/safe-mode data meaning

[adam.rob.carter]

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":[]
        }
    ]
}

[ahigginscassidy]

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

[rickkas7]

This may help

Safe Mode Published JSON String

That message in the event log indicates the system module configuration (describe message). Typically, when you enter safe mode, it’s because you have unmet dependencies (or you manually entered safe mode using the buttons). The dependencies look correct above. Understanding the Describe Message One of the places you may see the describe message is when safe mode is entered. It shows in the event log in the console: [events] But what does it mean? It’s a description of all of the software mo…

[adam.rob.carter]

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?

[rickkas7]

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.

[adam.rob.carter]

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?