• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 31 subscribers
  • Views 2051 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C129EKCPDT: Update Program

Michael Schuster
Intellectual 796 points
Part Number: TM4C129EKCPDT

Hi,

first I've to mention, I'm new to the TM4C129EKCPDT.

I have the following task: On the TM4C129EKCPDT system I am running an application, which is stored and booted from the internal flash. I want to have the possibility to update this programm, so I have an application based transfer (protocol via ethernet) which retrieves the update and stores it somewhere in the flash. After that is complete, the system is rebooting and will look in this sector and if there is an certain bit set, the bootloader will re-write the whole aplication with that, erase the bit and reboot.

I've seen, there are bootloader for running from SPI, etc. but I have no idea where to start from at this point. Can someone give me a hint?

Regards

Micky

  • 0
    Guru 13040 points
    Michael,
    Simple guidelines here:
    - Define a memory structure on your linker, and reserve a flash area to store the new firmware.
    - Create some sort of protocol to identify you are receiving a new firmware and to validate it.
    - Once received, set flags to determine the next boot's behaviour.
    - Use a separate bootloader in a small area of flash that verifies the status of your updates - and if necessary - copy the new one into the main memory sector.
    There are also some additional possible features you can implement. For example, it is possible to revert the old firmware in case the new one did not pet a watchdog after x seconds (bad new firmware), or even to force a revert using external control messages.
    Regards
    Bruno
  • 0 in reply to Bruno Saraiva
    Intellectual 796 points
    Hi Bruno,
    do you refer to the flash mirror mode of the TM4C? Is there any example? I didnot find this in the API and not really somewhere else.
    Regards
    Micky
  • 0 in reply to Michael Schuster
    Guru 13040 points
    Micky,
    I don't refer to any particular example. The "steps" above are just the grounds for what you are trying to achieve.
    The flash operations can be done with the Flash drivers in Tivaware.
    Regards
    Bruno
  • 0 in reply to Bruno Saraiva
    Intellectual 796 points
    Bruno,
    in the API I only see functions for erasing, writing etc. But the mirrow mode is not supported. So the job will be setting registers and try and error... sigh.
    Micky
  • 0 in reply to Michael Schuster
    Guru 13040 points
    Micky,
    The whole thing you want to achieve ain't a 2-day endeavour... It did take us almost half an year to get a solid library...
    But yes, it is basically just "moving bytes" from one location to another, and setting smart flags.
    I can share that the flash API's from Tivaware (and the hardware itself) have been working very reliably. We do use EEPROM to store those conditional flags and there is a separate custom bootloader to decide what to do.
    Regards
    Bruno
  • 0 in reply to Bruno Saraiva
    Intellectual 796 points

    Bruno,

    I finished my bootloader today and it works perfectly. I only didnot make use of the flash mirrow possibilty, as I didnot find a good documentation and obviously none of TI officials seems to have a tip here.

    Thanks at least for your basic tips!

    BTW: Did you make use of the RTOS or BIOS of TI? Do you have experience, does it have a good performance?

    Regards
    Micky

  • 0 in reply to Michael Schuster
    Guru 13040 points
    Hi Michael,
    That's awesome - and fast - congratulations!
    I did not use RTOS/BIOS, our coding here is all Tivaware and "pure" C. I've been discussing in other posts whether or not to adopt TI-RTOS, at least for the task scheduling control, but still we've been using some sort of house-made scheduler.
    Particularly on the bootloader, it does not have any scheduling or even a main loop - it became just a very small sequential program to check the eeprom flags and decide moving flash blocks or not.
    Cheers,
    Bruno
  • 0 in reply to Bruno Saraiva
    Intellectual 796 points
    Hi Bruno,
    That is my guess too, to work in "plain" C. The last time I evaluated DSP Bios for the C55x family (about 10 years ago), it was not really recommendable - but 10 years is a long time, so my question...
    The bootloader is really a small piece of code and some conventions in my work flow for the application program, but it's always that way: Problems disappear once you have the solution.
    Regards
    Michael
  • 0 in reply to Michael Schuster
    Guru 13040 points
    Michael,
    Just note that I did not really vote against using the RTOS. I just discussed, evaluated it a lot, and have not yet implemented.
    But it does seem to have some advantages: a very flexible scheduling engine, ease to control CPU load, and some other bells and whistles - which simply don't justify our efforts of giving up the limited-but-working current solution.
    Bruno