I was performing a dfu device os update on a Xenon from the files posted on github.
One question - what are the different firmware files? There are 3 seemingly system files and 3 variants of tinker.
bootloader
system-part1
hybrid
then there’s tinker, tinker-serial1-debugging, and tinker-serial1-debugging…mono
What is the difference? If I needed to restore the factory firmware, exactly which one/s do I need to load? What do the different versions of tinker provide?
The bootloader is the code that runs when the device first powers on. It’s small, and does not change on every release. It’s separate because it can only be updated by USB in --serial mode (not in DFU --usb mode), OTA, or JTAG/SWD.
System-part1 is the system firmware (Device OS). This is upgraded on each new release (0.9.0, 0.9.1, etc.) and is separate from your user firmware normally.
In general, devices run modular firmware which has one or more system parts (1 for Argon/Boron/Xenon, 2 for Photon/P1, and 3 for Electron/E Series) and your user firmware binary. The user firmware binary targets a particular minimum system version, but can be loaded separately, which speeds up the flashing process, and also greatly reduced data use when doing a firmware update over cellular.
There are also monolithic builds which contain both the system part and the user part in a single binary. These are typically used during debugging as the source level debugger works more easily with monolithic builds. Factory new Argon, Boron, and Xenon devices come with a monolithic build installed, because modular support was not ready at the time the devices were first manufactured.
Normally, you need to flash a device in DFU mode over USB (–usb) in order to switch between modular and monolithic.
The hybrid build is a special build that can be flashed OTA or by BLE that can overwrite the factory monolithic build with a modular system part. It also installs Tinker, if there is not already a valid modular user firmware binary installed. That’s how devices go from monolithic to normal modular from the mobile apps on initial setup.
Since the hybrid build won’t overwrite an existing user firmware binary, it may be necessary to manually flash Tinker to restore a device to a known state. There are three builds:
Normally you use a build like tinker-0.9.1-xenon.bin.
The build like tinker-serial1-debugging-0.9.1-xenon.bin is the regular tinker, but it also enables Serial1LogHandler to write debugging data to Serial1. This can be handy for troubleshooting connection difficulties.
The build like tinker-serial1-debugging-0.9.1-xenon-mono.bin is a monolithic debug build with Serial1LogHandler enabled. This build is particularly useful if you want to debug Boron issues because it will dump out all of the modem commands.
But to restore a device to a reasonably blank state you should:
Clear credentials by holding down MODE until the status LED blinks dark blue, then continue holding it down until it blinks blue rapidly.
Flash system-part1 and tinker in --usb mode (DFU, blinking yellow)
It’s not generally necessary to flash the bootloader, but if you do, make sure you do it in listening mode (blinking blue) using --serial mode because you can’t do it in DFU mode.
Great explanation, Rick!
I will bookmark this!
(especially that the bootloader can only be loaded via --serial and the instructions to go to a “reasonably blank state”. Maybe put a copy of this in the GitHub directory as a readme)
If you care to comment, this raises a couple other follow ups:
Is there a way to know if your device is using a modular or monolithic build? I guess the system automatically knows whether to flash mono or modular? I typically flash OTA unless I have a problem, then I flash dfu.
How would you define “reasonably blank”? This suggests the question, in addition to the bootloader, device OS, and app firmware, what are the other software components in the system? I’ve gathered that some devices (only 3rd gen) store backup app firmware.
I only ask that out of curiosity. I think that, when a device is not behaving, knowing how to go backwards to a a known good state (or the start) is needed. That’s what you wrote with your instructions to put the device in listening mode (dark blue flash).
Again, thank you for answering my original question!
There are several settings (e.g. WiFi credentials, mesh credentials, keys, sticky settings, ...) stored in the DCT area that should persist even a full replacement of all firmware modules - some of these (e.g. credentials) are also cleared during the process.
The Spark Core also had a factory image that was commonly used and IIRC Gen2 would too, but that was never really been officially used.
As long the factory backup location has no valid firmware stored in it, a factory reset will not touch the current application firmware, but once a valid firmware is stored there the currently installed application should be replaced on factory reset.
You can check in Listening Mode via particle serial inspect.
OTA updates via Web IDE will always try a modular application. If your device is currently running a monolithic one that OTA update will fail.
The same will happen when you try to only send a modular application to the device via particle flash.