CCS/TM4C123GH6PM: OVER THE AIR UPDATE FOR TM4C123GH6PM

Hello Siva,

Thank you for these details, you have presented a very solid summary of your requirements. While I can't assist with all of them, I will offer what advice I can to help your development.

siva p said:

• Detecting when the device should be in bootloader mode or application mode

This would be user defined. From your description, it would probably make sense to use a "Magic Packet" where if the GSM Module receives it, then it invokes the Bootloader with an API call. You may need to consider the timing of when the GSM module could receive a packet like this and determine if you want to instantly invoke the boot loader or wait for any processes to resolve beforehand - just application specific concerns to think about in the scope of your whole system.

siva p said:

• Validating the application

Validating an application is one of the trickiest parts of making an OTA boot loader. Typically the best method would be to use some sort of checksum/CRC to ensure that the data is not corrupted. That is what I would recommend.

siva p said:

• Redirecting interrupt vectors

This is straight forward and part of the bootloader process. Keep in mind that the bootloader itself should execute from SRAM so that if the Flash overwritten includes the bootloader itself, that it won't interrupt the programming.

siva p said:

• Jumping from bootloader to application

This again is straightforward as once the bootloader is finished writing to Flash it should have knowledge of where it has written firmware to and what address it needs to jump to in order to execute code.

siva p said:

• Recovering a valid image when in a Dual-Image mode

I am not sure what you mean by recovering a valid image, but if using dual-image mode then your memory would be broken up into 3 partitions. The first and likely smallest would be your application manager + boot loader. Then your remaining memory would have to be divided in half to have equal space for each image. From there the application manager + boot loader would need to keep track of which of the two images has a valid application. If one has a valid application, and the other doesn't, then the non-valid application should always be prioritized for writing new firmware.

Once validated, then it can be set as the valid application and the boot loader can jump to it for execution. If you want to try and recover a program by copying the flash contents, that could be possible, but I am not sure that would end up being beneficial as you shouldn't see any difference in performance from executing from different sections of Flash so to me that step sounds redundant as long as the application manager is well crafted. The only benefit it really would have is making the memory mapping from a documentation standpoint more straightforward at the cost of needing to copy contents across Flash.

If you really want to have a separate download area, you can do so, but once the new application image is verified as functional I see little reason to transfer it over to an 'Application Area' for execution since the end of the boot loader process lets you determine the start point for execution anyways. Just my two cents.

siva p said:

Detecting when the device should be in bootloader mode or application mode

TI has examples of the bootloader checking a button press. You could change this check to some byte of NV memory (EEPROM maybe) set by the application before calling the bootloader. The tricky part is you always boot into the bootloader, so it needs to know when to take update action and when to send the CPU off to your application code.

In most examples, the bootloader expects the firmware to come in through some interface (UART, USB, Ethernet, etc). Your case is a bit simpler since you already have a downloaded image somewhere.

siva p said:

Validating the application

Examples use a CRC check and TI provides source code to build a windows app called binpack. Binpack embeds a CRC to your firmware .bin file.

siva p said:

Redirecting interrupt vectors

From the chip's datasheet "Register 57: Vector Table Offset (VTABLE), offset 0xD08

Note: This register can only be accessed from privileged mode.
The VTABLE register indicates the offset of the vector table base address from memory address 0x0000.0000."

You set this register to wherever you applications vector table is downloaded to.

siva p said:

Jumping from bootloader to application

The stack pointer is set. Then you branch to the application's reset vector.

siva p said:

Recovering a valid image when in a Dual-Image mode

This is not provided in examples. I assume the merit here is you can run the newly downloaded image for a while and jump back to the existing if you experience problems. Assuming the CRC passed, the image should run as tested in the lab. I would include this feature if you're working on something important like a nuclear reactor, but it doesn't seem essential for most cases.

If you are set on a dual image, there may not be a reason for a temporary download area. I would make the gsm module download the image to the space not currently running. This saves you a copy procedure.

Edit: I had not noticed Ralph's reply while typing this. I hope my information is complementary.