storing a golden image in the unused program memory

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been thinking of ways to avoid sending a technician to repair a failed firmware update. I'm not sure if this will work, but it would be nice if it did.

I'm using an xmega8e5, which has 8 kB of ROM. The program uses approximately 1 kB, so there's plenty of free space. Instead of using an external flash to store a golden image that the bootloader can use in case the firmware update fails, can I store code in the unused program space? I think the bootloader would simply page erase starting at 0 and then only as far as it needs to go, which would leave the golden image untouched. For example, if the golden image is 1 kB and I store it near the end of the program space, erasing the first few kB should leave it intact. Should the firmware update fail, the bootloader can read the golden image from program memory and then program it into the live program memory section, i.e. starting at address 0.

Thoughts?

Last Edited: Sun. Dec 8, 2013 - 05:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely if the bootloader is properly designed and implemented, you should simple be able to restart the re-flashing procedure and try again.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the image being flashed is corrupt, the board is toast until a new image can be acquired. Allowing my customers to continue working from an inferior, but still functioning, image would be far better than shutting down an assembly line for hours or possibly days. I can think of several other reasons a golden image would be helpful, but that's not the point of this topic.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not just execute out of the backup rather than copy? That is just another operation and would take additional code to do the copy. It might be a bit tricky dealing with ISRs, though.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been wrting firmware and bootloaders for years, and I always arrange that the bootloader gets a look in at reset. There is no way my clients would tolerate a situation whereby "the board is toast.
How do you distribute firmware upgrades? If they're broadcast via RF or something than I can understand your concern.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bootloaders 101: making your embedded design future proof by Trevor Davis & David Durlin (Cypress Semiconductor, embedded.com; March 19, 2013)
describes a multi-application bootloader (search for "multi")
and a graphic in Figure 3: Memory map of bootloader and application locations
Article states the bootloader's host declares which app to load.
Could add function to the apps to declare which app to load.
A use for multi-app boot is in DBS receivers; an example of a bootloader that remotely receives signed and encrypted applications and an app must always run.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I totally agree with John. No one should ever write/use a bootloader that cannot handle crash recovery. You never know when some idiot is going to disconnect the power half way through an update so a decent bootloader will always be able to recover simply by restarting the process at next power on until it runs to completion. BOOTRST shoukd always be used and while the app can share dependencies in the bootloader code the bootloader can never rely on anything the app may have or do (because sometimes it may not be there).