4 ms·

Here's a practical application: I have a device with 512k flash. I use 64k for a bootloader, 208k each for two possible application versions, the rest for sett

Here's a practical application: I have a device with 512k flash. I use 64k for a bootloader, 208k each for two possible application versions, the rest for settings. If I can use relocatable code, I can download a new firmware version during normal operation of the device with no need to switch over to the bootloader. When it's time to switch version, a quick reboot is all that's needed. This means downtime of a second or two instead of several minutes, and that's very valuable. A possible work-around is to prepare two binaries for each firmware version, one per possible location, but then I'd need to negotiate with the device to know which image to send. Better to just have one image fit any location.

scoutt 5y ago
Ok. Your explanation was clearer to me than the one from the article. But still, how does your bootloader know which version to use? What I did many times in the past is to have two areas in flash: "normal run" and "update". "Normal run" has the running firmware and "update" is an area where the running firmware will use to store a new version. It goes like this: the new firmware version is flashed to the "update" area in flash, usually with a header and a checksum. Then the bootloader will check for this header/checksum in the "update" area and if valid, will flash the contents of "update" area into "normal run" area. Then the contents of "update" are invalidated (erased) and the bootloader jumps to "normal run" as usual. If any of the above fails, the firmware will be just re-written. The above is also valid for checking if the new firmware is authorized to run (signed, whatever). I know some Nordic chips have special registers for this purpose.
- m_eiman 5y ago
  In our case the images contain some meta data, including version and checksums. The bootloader can default to starting the newest version, and be sure that everything is fine by checking the checksum. If needed the bootloader can be instructed to either remain in bootloader mode (to receive a new firmware image) or to start the older firmware.

scoutt 5y ago

Ok. Your explanation was clearer to me than the one from the article. But still, how does your bootloader know which version to use? What I did many times in the past is to have two areas in flash: "normal run" and "update". "Normal run" has the running firmware and "update" is an area where the running firmware will use to store a new version. It goes like this: the new firmware version is flashed to the "update" area in flash, usually with a header and a checksum. Then the bootloader will check for this header/checksum in the "update" area and if valid, will flash the contents of "update" area into "normal run" area. Then the contents of "update" are invalidated (erased) and the bootloader jumps to "normal run" as usual. If any of the above fails, the firmware will be just re-written. The above is also valid for checking if the new firmware is authorized to run (signed, whatever). I know some Nordic chips have special registers for this purpose.

m_eiman 5y ago
In our case the images contain some meta data, including version and checksums. The bootloader can default to starting the newest version, and be sure that everything is fine by checking the checksum. If needed the bootloader can be instructed to either remain in bootloader mode (to receive a new firmware image) or to start the older firmware.