RTOS/TM4C129XNCZAD: boot_emac_flash failsafe

Hi Peter,

Peter Borenstein said:

Is there a version of boot_emac_flash which allows reverting to current (older) firmware after an error from attempting to download a new image?

If not, is there a similar boot loader option which does this?

If no to both, how might the boot_emac_flash be altered to gain this feature?

If an Ethernet firmware update fails, I need the ability to revert back to the current image. boot_emac_flash seems to erase the current application code as a new application image arrives. A failure halfway through the download would make reverting impossible because half of the current image has been erased.

No, there is no such bootloader version that will revert back to the current image. As soon as you start the update the current image in the flash memory will be erased first. 

In the TivaWare example, the application will call the update routine in the bootloader (boot_emac_flash) to start a new update. What you can try to do is to build some intelligence into the bootloader such as that at the end of a successful update an unique key (i.e. 0x12345678) is written to a predefined address in the flash memory.  If the update fails in the middle then that unique key location will still be in an erased state. The bootloader will not only check if the new application has valid stack pointer and the reset vector but also this unique key location. If the unique key location is not written then the bootloader will force an update again for image A. I think in the BOOTP packet request, you can specify the corresponding bin file name. See the boot filename field in the BootP message format. However, I think you need to have the BootP server to decode the boot filename field so the bootP server knows which application image to update. I don't think LM flash programmer supports that today. 

Peter Borenstein said:

I am aware of boot loaders that have 2 images. The memory is split in half and the newer image is downloaded to a different area of memory without deleting the current image. Is a dual image setup safer than downloading one image over another? In this configuration, would it be best for image A to download image B, or let the boot loader download image B?

The TivaWare application example will transfer the control to the bootloader to update new image. The application does not directly download new image by itself. I will suggest you follow the TivaWare example. 

Peter Borenstein said:

TivaWare has application code that will receive the "magic packet" sent by the LM Flash Programmer in swupdate.c. This example code uses lwIP. Is there TivaWare code that uses TI's NDK instead?

No, the TivaWare examples do not use NDK. 

Charles Tsai said:

then the bootloader will force an update again for image A

This is the very pitfall I am trying to avoid.

Defining ENFORCE_CRC has a similar effect as your key idea. To insure the new image is completely downloaded successfully, a calculated CRC is compared to a pre-calculated value located after the vector table.

A missing key or bad CRC both result in the device being a brick if connection to the BootP server is lost mid-download.

What do you mean the device will become bricked? The bootloader will just keep sending BOOTP request until the BOOTP server is recovered. If the BOOTP server is forever dead then I agree that the client will do nothing but only sending BOOTP requests indefinitely. If this is what you worry about then you need to somehow save your original firmware image in the part of flash that is not to be erased. Hopefully you firmware image size is less than the half of the total flash size. If your FW image is larger than half of the total flash then your option is to save to external memory first.

While you are investigating the recovery options for your firmware, I will suggest you do the same to your BootP server. Why would it be in an unrecoverable state and how to prevent that?

Hi Peter,
Have you had success with with the two image approach?