I’d like to update the device OS, which seems simple enough, but one should always make backups before messing with such things… yet despite plenty of documentation on how to perform an update, I can find nothing on how to back up the current firmware.
The only reference I can find is this thread, which specifies the command:
dfu-util -d 1d50:607f -a 1 -s 0x00020000:0x00022000 -U backup_frfirmware.bin
I’m a bit wary of trusting an old, undocumented command from a community user with magic numbers i don’t understand - is that address range correct? How am I to know it will work?
Hi Gustavo, thanks for the reply.
I’m not sure how to get the ‘star’ - I’ve got no such icon.
The default device OS target, as shown in your screenshot is 1.4.4.
I’m not sure what you mean by having the firmware code handy. I have the application source code, but not a compiled binary file. From reading the docs i’m under the impression that if i try to re-flash with the sourcecode again, it’ll result in it being recompiled against the latest deviceOS firmware, which will then be incompatible with the device, which will do a self-heal update. I’m trying to do a backup, before the update, so perhaps I missed the point there.
ok, no star would mean you have only one device, which I think is your case.
So, you can paste the application source code right there, on top of the default code (void setup()… that you see on the right panel).
You can then proceed with the save, compile, flash buttons you see on the left.
Well, I have a working system, and if, for some unexpected reason, updating breaks it, I would like to be able to restore it to the way it was before. … that’s generally the idea of backups.
As Gustavo already pointed out, you can select which device OS you will be building against.
So there should not be any need to backup the current binary from the device.
Also once you built your code you can download the resulting binary as well as the project sources - this would typically be the better way to backup the originals rather than flashing the binary to the device and then pulling it off the device again for backup.
$ particle serial list
Found 2 devices connected via serial:
/dev/ttyACM1 - - undefined
/dev/ttyACM0 - - undefined
$ particle serial inspect
? Which device did you mean? /dev/ttyACM1 - - undefined
Could not get inspect device: Serial timed out
Edit: apologies, didn’t spot that it had to be in listening mode:
$ particle serial inspect
? Which device did you mean? /dev/ttyACM1 - - undefined
Could not get inspect device: Unexpected token : in JSON at position 3
Have you tried the other device?
If your computer can’t decide which device to use you can specify it via the --port switch
> particle help serial identify
Ask for and display device ID via serial
Usage: particle serial identify [options]
Global Options:
-v, --verbose Increases how much logging to display [count]
-q, --quiet Decreases how much logging to display [count]
Options:
--port Use this serial port instead of auto-detecting. Useful if there are more than 1 connected device [string]
Unfortunately I haven’t got any Cores anymore, so I cannot test but maybe @rickkas7 can.
He’d also be able to assist with the binary download from the device and how to flash such a snapshot back.
The command you quoted above should still work.
1d50:607f stands for the vendor and device IDs the USB controller should be applying the command to.
0x00020000:0x00022000 stands for the address space to backup
Trying the other device gives time out. I can otherwise communicate with the core over ttyACM1, for example to set wifi credentials, which gives me the impression this is the right port.
Perhaps unrelated, but I do note that dfu identified the device ID as different to what the docs suggest, in case that provides a hint
Supposedly a Core is expected to be [2b04:d000]....
0x00020000:0x00022000 stands for the address space to backup
I guess this is the only bit that concerns me, to know that this address space is correct... i'm not sure if it changes between versions, or devices (especially considering my device ID is not according to the docs...)
$ particle serial identify
? Which device did you mean? /dev/ttyACM1 - - undefined
Your device id is 5*******************7
Your system firmware version is 0.5.1
It seems like that identified it! … so in theory i can rebuild against this OS version from build.particle.io…
I see, thanks for clarifying on the device ID. I was going by this page - the docs are already pretty hard to find for this device!
I must admit especially given how “deprecated” this already is, having a local backup of a working firmware seems like a prudent idea all the same.
OK, so this thread seems to have died a death, yet the topic remains unanswered.
I still don’t know how to retrieve the device OS off my device.
Let’s try to motivate why that might be a good idea.
The last post established that I’m apparently running deviceOS v0.5.1. I go to download the deviceOS firmare binary files off github…
…but find that despite being listed for Core/Photon/P1/Electron (that’s 4 devices) that page has the following downloadable assets:
… that’s 3 devices. Guess which one’s missing.
Well why be so attached to version 0.5.1 anyway? Why not just update? OK, so I updated my device to firmware 1.4.4. After all, I can re-build and reflash for 0.5.1 if need be by selecting it from the drop-down menu shown in post #3.
So I upgrade. And my device stops working. Repeated reboots, SoS flashing code 11. The same user application code that worked just fine on 0.5.1 now dies with “invalid case” on the latest (final) release build for the Core device OS.
So, ok. I skip ahead a few versions and have now built against 0.5.4, and the code is working just fine… for now. But again, release 0.5.4 has no files for the Core!
So, either I sit here playing whack-a-mole, hoping to find a release with firmware files for the Core that also doesn’t crash, or I grab the firmware files straight device… i.e. the thread topic.
The Core does not have a separate device OS module. Its firmware is monolithic.
That means when you build your application against a particular device OS version the resulting binary will contain both Device OS and Application firmware.
That's also reflected by the fact that the Tinker binaries for the Core (downloadable at that same place) are much bigger than the binaries for the other three platforms.
The Core does not have a separate device OS module. Its firmware is monolithic.
That means when you build your application against a particular device OS version the resulting binary will contain both Device OS and Application firmware.
...
Hence, build the binary and download it and back it up.
Oh! Well that's nice to know, I do have the built application firmware saved from the web IDE, so I guess that means i have the deviceOS backed up as well. I must have missed that in wherever it was documented (perhaps it could be mentioned on deviceOS release posts?), thankyou.
That’s an indication that the code may have some flaws that don’t survive the stricter scrutiny of the more advanced/stable versions.
Quite possibly - I didn't write it, and to be honest, if it works (with an old deviceOS), I don't have the time to spend debugging it.
That said the investigation I did do found that this behaviour was caused by 6 lines in the code:
It seems as though UDP broadcasts had ongoingissues with the Core. I've modified the code with all the 'success' tips i've found - enclosing the code in an if(WiFi.ready()), reading any echoed packets back, adding delays, but with no change in behaviour. Notably it crashes on the first loop() invocation, so this code never even runs, leaving me rather puzzled. But as they say, if 0.5.4 ain't broke, don't fix it.
)
