This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1294NCPDT: Using the flash for updating the firmware

Part Number: TM4C1294NCPDT


Hey, I am currently working on a project in which we are looking at options for the MCU.
I'm currently looking into using the MCU in the title. However, I have some questions I would like to hear if someone could help me with concerning using the flash as a boot loader for firmware updates.

The on board flash has 4 memory banks, with 2 x prebuffers, and is 2 way interleaved, so the intention is that two of the memory banks are preserved to hold new firmware until it is fully downloaded, and then do CRS's etc. to check the content. After which, it is either transferred to the other half, or the system will boot from the new location and the old firmware is deleted, as well as changing those banks to hold the next firmware update. Something like that.

My questions are as follows:
If I want to change something in the flash is it necessary copy the entire memory bank into the SRAM, change what ever data needs to be changed and then overwrite the bank again. Or can specific data at any address be changed in the flash?

The half of the flash that is used for to store incoming firmware updates, at normal operation, may that space be used for volatile data eg. data logging of operation. Or is it necessary to keep those banks in a specific level of code protection to boot the firmware from that bank?

And is the TI DFU mode helpful if this is how firmware updates are handled?

Lastly, I would like to ask if anyone has any data on the rewrite number of the flash on this chip. As I have not been able to find information on the specific flash.

Beforehand, thanks for the help.

  • Hi David,

    My questions are as follows:
    If I want to change something in the flash is it necessary copy the entire memory bank into the SRAM, change what ever data needs to be changed and then overwrite the bank again. Or can specific data at any address be changed in the flash?

    Flash is different from EEprom. You must perform a flash erase before you can write new data to flash. In another word, the flash bootloader will so for you. It will erase the application firmware in the flash first before updating it with new firmware. Please refer to Bootloader user's guide for more details. https://www.ti.com/lit/pdf/spmu301 There are quite a few bootloader examples in TivaWare library. I will suggest you start with boot_serial (this is a flash-based bootloader) starting at 0x0 and boot_demo1 (this is an application example to be loaded at 0x4000 by the bootloader through UART interface). 

    The half of the flash that is used for to store incoming firmware updates, at normal operation, may that space be used for volatile data eg. data logging of operation. Or is it necessary to keep those banks in a specific level of code protection to boot the firmware from that bank?

    Although you can use internal flash to store volatile data, however for data logging, I will suggest you use on-chip EEprom. EEprom size is 6kB. EEprom serves the purpose for data logging. It has built-in state machine to handle wear leveling for high endurance write cycles. Please find below excerpt or datasheet for details. 

     

    And is the TI DFU mode helpful if this is how firmware updates are handled?

     There are multiple communication interfaces through which for firmware updates. USB DFU is one of them. You can also use UART, SPI, I2C, CAN and Ethernet to bootload/update your firmware. Please refer to the boot_demo_usb example. boot_demo_usb is a simple USB application example that will turn into a DFU class that allows the USB host to download a new software image.   

    Lastly, I would like to ask if anyone has any data on the rewrite number of the flash on this chip. As I have not been able to find information on the specific flash.

    This is shown in the datasheet. 

      

  • Thanks, this clarified some things.