Feature Request: Remote User Firmware Wipe

Firmware
1

The biggest benefit of the Spark Core (wi-fi) can also be a hindrance. If I flash some bad code that SOS panics a remote Core, it can be difficult to manually get to the Core to perform a factory reset, reconnect to wifi, etc. It would be nice if there was a way to set a flag to remote wipe a Core when it next comes online. It could re-flash with the default Tinker but still leave the wi-fi credentials intact. That way, when we see the Core come back online, we can re-flash with user code.

Basically, I accidentally flashed some bad code from the Sparkulator to a Core set up at home, and Iā€™m stuck here at work. The code reliably SOS panics and then reboots frequently, so I canā€™t re-flash the Core from the Sparkulator until I do a manual factory reset and reconnect to wi-fi. The ability to set a ā€œnukeā€ flag that the Core checks before running user code could help save me from myself.

4 Likes
2

And by NUKE flag, I assume you mean something in the CLOUD, possibly set by the Sparkulator GUI or through the Spark API. All Cores would have to be functional enough to briefly check in with the Cloud before running user code, check the FLAGs, and then run codeā€¦ or not. I like it :smile:

3

Obviously.. a mushroom CLOUD.

The (default) Cores already check-in with the cloud before they run user code, right? Maybe an extra flag could be sent during the initial handshake/hello so that an explicit call doesn't have to be made to the cloud, thus maybe keeping RAM usage lower and one less request/response cycle (keeping the "boot" time the same).

Or, I could be completely making that scenario about the handshake/hello up in my head. I am very much a novice when it comes to C, but I spent about 2 hours or so last night looking through the GitHub repos to try and figure out how this tiny piece of brilliant ingenuity works. :wink:

4

I think this has been made possible but not to us for now.

Saw the branch on github for the CC3000 OTA patch and a flag will be set for records on whether the core has been updated or not.

Similar to what you want about the flag :slight_smile:

5

I donā€™t think I looked at the CC3000 patch repo last night. Iā€™ll look through it tonight, though!

1 Like
6

See the branch in core-firmware repo.

7

I guess I don't understand how you want to set the flag. Define the source and destination of the flag travel please :smile: I still like my way fwiw.

8

Set the flag by clicking a button or checkbox in Sparkulator (or spark-cli or API). I was just thinking that maybe the ā€œnuke checkā€ could be sent as an extra bit on the end of an existing authentication call. That way thereā€™s not an extra call to the cloud just to see if a bit is set. It just seems like a lot of overhead to make another request, wait for a response, then parse a single bit out of a packet.

(For the record, I started this reply on my laptop, and then moved to my iPad to give the kids a bath. Discourse is clever!)

1 Like
9

Iā€™m looking for that iPad app but cannot find it.

10

I just opened the site in Safari. It syncs drafts of your in-progress posts to the server. I'm seeing several intermittent Ajax posts to the server. That way it can load up what you were typing on (most?) any browser you log in with.

11

The "bathe kids" button is greyed out on the Android version.

1 Like