• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 29 subscribers
  • Views 253 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/TM4C123GH6PM: Dual bank firmware upgrade support in TM4c123

Naman Trivedi1
Prodigy 115 points
Part Number: TM4C123GH6PM

Tool/software: Code Composer Studio

Hello,

I am using TM4C123 in our project. I want to have firmware upgrade through USB for my project. I have gone through example and successfully I was able to upgrade the application via USB.

I want to implement fail-safe mechanism in my application/bootloader. I am planning to have 2 banks of firmware - Active and NonActive banks (Non-Active bank can be in the internal or external flash memory) . In any case, if the new firmware doesn't work properly, I want the bootloader to switch to the older firmware which was running on the board previously. 

Is this possible with TM4C123 controller? Is there any application I can refer? 

Regards,

Naman

  • 0
    TI__Guru 72500 points

    Yes, it is possible. I do not have any such example. It is very application specific as to how you determine one version of the application is not working properly and cause execution to transfer to the other version of the application.

  • 0 in reply to Bob Crosby
    Prodigy 115 points

    Thanks, Bob for the reply.

    Let me explain this in more detail if it helps to understand my requirements:

    I want something like this:

    • Flash memory has two different addresses X and Y for saving the application

    • After the execution starts, the application should write some register/reset a timer that is shared with bootloader. If this register value is set, the bootloader marks the running application as valid.
    • The currently running application copies new firmware from USB stick to address Y
    • Bootloader loads application from address Y
    • This application could not set a register/could not reset a timer so this application was not marked as an valid application
    • Bootloader resets the controller and now valid application from X address is loaded and starts execution

    Let me know if this simplifies what I am planning to implement. This is what I have though theoretically. I would like if this is feasible without dual partition flash memory or if we can partition the flash memory for this purpose.

    Thanks,

    Naman

  • 0 in reply to Naman Trivedi1
    TI__Guru 72500 points

    Here is a suggestion. Use a flash based bootloader with two modifications from the example. First, instead of checking a fixed location to determine if a valid application has been loaded, check a EEPROM (emulated EEPROM) location. If that location contains anything other than a valid flash sector start address then stay in the bootloader. If that location contains a valid flash sector start address that is not zero, then check the first two words of that location for a valid stack pointer and application start address. If found, jump to the application.

    The second modification is that after programming a new application, before jumping to that application enable the watchdog timer to generate a reset. 

    You first start with only a bootloader. The EEPROM location is blank (0xFFFFFFFF) so you stay in the bootloader. You load the first application at 0x1000 for example. The application runs properly and feeds the watchdog as it runs. Once it determines it is working properly, it programs 0x1000 into the EEPROM block. 

    Now application one is informed that it needs to be updated. It transfers control to the bootloader. Application two is loaded at address 0x4000. If the application fails to run properly and the watchdog timer is not serviced, the device is reset. The bootloader sees 0x1000 in the EEPROM and returns execution to application one. If application two runs properly, it changes the EEPROM location to 0x4000 so future resets will cause application two to run.