Backup Firmware - How do I use it? What conditions cause it to load?

Firmware
1

Hello,

I loaded a 'backup firmware' image onto my Boron device using the following command:

dfu-util -d 2b04:d00d -a 2 -s 0x80200000 -D tinker-1.4.0-boron.bin

This appears to have been successful as no errors were generated.

My question is, is the ONLY way to have the Boron load this image using the physical buttons? Or is it possible to have the device automatically load this image after a failure to boot (which would be ideal)?

Is there a method to load the backup image on demand in code? I was thinking something like:

if (System.resetReason() == RESET_REASON_PANIC) {
System.loadBackupFirmware();
}

Or possibly increment a counter in the backup SRAM and when the firmware has reloaded too many times, load the backup firmware?

Thanks.

  • Chris
2

Welcome to the community.
How many times have you encountered this failure to boot that requires a solution to recover the backup firmware image? Sorry this isn’t an answer - I am curious about solutions to problems like this? Is it not something you would pick up in testing before release into the wild?

3

The backup firmware slot is used if it’s written to, and one of two cases:

  • The button sequence is used to restore factory firmware

  • The user firmware slot does not have a valid image (erased, bad CRC, etc.)

During an OTA firmware update, the firmware is written to the OTA slot, then verified for a valid CRC before being swapped into the user firmware slot, so normally a corrupted image does not occur. However, it could occur if the power was lost or the device reset while swapping in the user firmware slot.

There’s no way to restore factory firmware from user firmware code.

4

Thanks for the quick reply. I was afraid that was the case. It would be nice to see the system fail over if there is a PANIC from the valid code running in the user firmware slot. Do you expect that to ever be the case?

5

No, because that’s not what the factory reset slot is intended for. Because you can only flash that slot by USB, you can’t field update it OTA, so that will eliminate many use cases. It’s typically used to restore Tinker (if not for the fact that we did not put Tinker in the backup firmware slot in the factory).

One thing you can do is detect the reset reason early at boot. For panics, rolling reboots, etc. you can then force the device into safe mode from your code. This will reboot the device but not run your code, which can provide time for new code to be flashed OTA.

6

I think that providing a mechanism to restore the backup firmware from code would be very useful. Even though it’s not field updatable it would allow us to restore to a known state. Safe mode is fine if you don’t use a third party SIM and need custom connection settings. I for instance do not use Particle cloud, so safe mode is not really useful in my case. I know Particle is pushing for everyone to use their cloud, but for a variety of reasons it’s not currently practical for my application.

2 Likes
7

While I do wish there was a way to code a jump to the backup firmware, this does answer my question.

Another thought, is it possible to scramble the CRC or user firmware code as stored on the flash to force it to fail over to the backup firmware? Or does the particle device os prevent writing to those locations?

Thank you.

  • Chris
8

Hmm… try this:

System.factoryReset();

it’s not documented but it exists and appears to be implemented.

1 Like
9

I will give that a try. Thanks!