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.

programming/updating flash using ssi0 and EEPROM

Other Parts Discussed in Thread: TM4C129EKCPDT, LMFLASHPROGRAMMER

Hello,

I am developing an application and we are using the TM4C129EKCPDT. I want the ability to remotely reprogram our device by downloading and storing a new flash image to an EEPROM attached to ssi0 and then initiate an internal reprogram of the chip. I realize that the factory bootloader does not support this type of ssi flash reprogramming and I will have to develop my own bootloader. 

My thinking is as follows.

1) download/save and verify  the image to the EEPROM.

2) initiate the reprogram procedure by setting an IO and resetting the chip

3) when the chip resets it sees the IO and loads my custom bootloader to RAM and reprograms the flash

4) reprogramming complete and verified so reset the IO and then reset the chip to allow it to run the new image

 Does this seem reasonable and is there any documentation/examples around that could help me out in developing this?

thanks for any input

 

  • I forgot to add that there is no network connection and the image would be downloaded using a UART (1 or 4) connection (zigbee or rs-485) and UART0 is being used for inter device CANbus communication
  • Hello Russ

    You would need to update the Flash Based boot loader in a two step process

    1. Step-1 Migrate the code of UART-0 in flash boot loader to another UART and test it out with the LMFlashProgrammer

    2. Step-2 Add the API call for programming the EEPROM via SSI Interface and addition of the copy from EEPROM to RAM to Flash

    While this is reasonable, I would suggest getting Step-1 correct and creating the API's for the EEPROM download of an image first. Rest we can help build it with you.

    Regards
    Amit
  • Alright, next scenario.
    I am wasting too much time trying to get the onboard bootloader to work and I won't be able to use it anyway.

    My next bootloader idea is:

    The original image will always be loaded into flash using jtag (at production).


    This code will contain a section of RAM that I will copy my bootloader routine into. This means it will always be resident and occupying a section of RAM under normal operation and I have the space to live with this.
    During normal operation I will download and store the new generated hex file and store it on the EEPROM I have on ssi0
    A command will then be sent to start the bootload sequence.
    The bootload sequence (in RAM) will erase the flash using code based on FlashErase() from driverlib/flash.c
    After erasing the flash it will read the hex file from the EEPROM and program the flash using code based on flashProgram() from driverlib/flash.c
    at the end of programming flash the sequence will reset the chip to start running the new image.

    is this feasible?
  • Hello Russ,

    The boot loader will always reside at location 0x0 onwards and application image from the next page boundary such that an erase does not affect the boot loader. You will need to know that when programming the Application image the first 2 locations which have the SP and PC must be flashed in the last.

    You would need to have a re-update mechanism as well.

    Regards
    Amit
  • Thanks for your help amit,

    The hex file I will be using is the intel format output (--intel option) generated by the ARM hex utility in code composer 6

    A couple of points for clarification

    quote - The boot loader will always reside at location 0x0
    I assume that this is the ti bootloader that cannot be removed and I have to avoid it during an erase or would this be the start address for my custom bootloader?

    quote - the SP and PC must be flashed in the last
    I assume programming the flash starting from my highest address ending at 0 will accomplish this. Am I correct?

    quote - re-update mechanism
    would this be some sort of mechanism to recover from a bad flash update?

    thanks again,
    Russ
  • Hello Russ

    1. Yes. The Boot Loader is the custom code that can select between the UART's as interface for getting the Application image and must not be erased.

    2. You can flash all locations in the order except for SP and PC. The reason is that when the boot loader hands off to the Application code it should check if the SP-PC look valid. If there is a power failure during the boot image copy, this way you can prevent execution of a partial application code. This is not 100% fail safe but it is better than having a junk code.

    3. Yes and No as it depends on how the boot loader code is written and all checks that are being done.

    Regards
    Amit