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.

Compiler/TM4C129DNCPDT: Custom Bootloader Loading Firmware to Non-standard Memory Location in Flash

Part Number: TM4C129DNCPDT

Tool/software: TI C/C++ Compiler

Hello everyone,

I'm developing a custom bootloader for the TM4C129DNCPDT. We need to perform code updates using UART1, and because Tiva's built-in bootloader can't be used on that UART channel, we need to build our own (if it can be used, please point me in the direction of the documentation, my understanding is you can only use it with UART0 or USB). For what it's worth, I'm using TI-RTOS in addition to the TivaWare library.

In addition to this, we want to have a special setup in the flash. We want two locations where our program will live. The idea is that we always have a working version of code in the flash, so that if a code update fails, or the file is corrupted, we can fall back onto the original code, and the processor continues to function. What this means, however, is that we need a second location in flash to place firmware. 

I have a few questions regarding all this:

  1. The FlashProgram function will place bytes directly into Flash. If I use the .bin file generated from calling "tiobj2bin" and use FlashProgram to place the .bin file into Flash, will my code run as expected? If not, what do I need to do so that FlashProgram will properly put my code into Flash?
  2. Is the addressing of functions relative or absolute? Meaning, if I have code at location 0x00000000 and a new version of code Flashed at 0x00050000, will my new set of code just jump/branch back to the old code when a function is called? Or would the function calls jump to the new code locations? Could this be a linker setting?
  3. How might I limit the available Flash to my program, to avoid overrun? I believe it's through the .cmd file, but I haven't had to do this before, so I just want to make sure.

I hope this makes sense, I know this is fairly complex and different from Tiva's general bootloader. If some of my questions would be answered via documentation, please point me in the document's direction. Thank you for your time.

- Tom

  • I have no expertise regarding boot loaders.  But I can shed some light on ...

    Thomas Jacobson said:
    We want two locations where our program will live.

    The TI ARM compiler has no support for your request.  Functions must reside at one address.  The same is true of global data.

    Thanks and regards,

    -George

  • Thomas Jacobson said:
    We want two locations where our program will live.

    The TM4C129 parts with 1Mbyte of flash have flash mirroring which allows multiple copies of software to exist in Flash simultaneously, with hardware address translation to swap the addresses of the upper and lower banks. See section 8.2.3.3 Flash Mirror Mode in the datasheet.

  • Hi guys,

    Thanks for your responses. I think I need to clarify a bit more. Our product would initially have one version of firmware loaded onto it. When it's time for a code update, we'd write the new firmware to an alternate location, then run from there. If there's another update, it's written to the original location, and then we run from there, ping-ponging back and forth every time we need to update the code.

    I think the Flash Mirror Mode is exactly what I'm looking for, but I'm not sure how to implement it. Would I simply call FlashProgram() until the upper bank is fully loaded, and then set the FMME bit? Do you happen to know of more documentation related to the Flash Mirror Mode, or perhaps an coding example?
  • I wish I had an example for you (it would be a fun one to write if I could find the time). The concept is that the first part of the code, the bootloader, is the same in both the lower and upper memory. You read something to determine to mirror the flash or not. Perhaps an emulated EEPROM value. When programming code into the upper half, you can have your bootloader offset the address, or you can specify a separate LOAD address from the RUN address in the linker command file.