TM4C1292NCPDT: changing of firmware image executable address without hardcode

Hi Sandra,

Perhaps I'm not clear with your question. Your two images are to be allocated to the two addresses, i.e. 0x4000 and 0x8400. How would you compile/link your two program images if the cmd file does not specify where they will be allocated to?

Three words Charles,

Position Independent Code.

Robert

Practically a requirement for a fail safe bootloader

Hi,

If an image is to be executed from flash memory, and address is not known now, means image address is not fixed as 0x4000 or 0x84000, then can I fetch image address from my boot code? Is there any way like, to fetch this address to a variable stored in eeprom and to load it later?

Regards

Sandra

Hi Sandra,
Not sure if you are looking for PIC as suggested by Robert. I have no experience with PIC code. If that is what you are looking for then we need to check with the Compiler team as I'm not even sure if this is supported. But if you simply just wanted to store the addresses; 0x4000 and 0x8400 in EEprom I don't really see a problem. It is not much different than what you are currently doing where you have a variable in EEprom that decides which image to execute.

Hi,

Thank you for your reply.

Regards

Sandra

Hi Sandra,

This is not a direct answer to what you are asking, but a workaround. We also faced the same need before.

I don't know if CCS can handle this Position Independent thing that Robert mentioned... but I would assume that one way or another, this indirect address shifting would require additional resources during execution. We decided not to learn it.

Hence, what we do is to ALWAYS compile the main code to run from a fixed location configured in the .cmd file. An eventual firmware update is actually stored somewhere else, and during boot, if needed, the new firmware candidate is copied to the default location.

If our target codes are "small" (in practical terms, a bit less than 1/3 of the MCU's flash size), three copies are always kept in Flash: CURRENT, RESTORE and CANDIDATE. If firmware is larger than that, then the same concept is used, but an external flash memory is used (or the RESTORE version has to be discarded, which is kind of not-so-safe).

Cheers

Bruno

Thank you, Bruno for your insights!

Hi Charles,
Glad to be able of helping a bit!
This subject of managing firmware updates is a recurring matter, and I believe that we could together come up with a "complete library" to enable such. My team, with the help of not-so-active-now poster Luis Antonio, already created a quite decent and reliable solution - but still there are a few functionalities we could add to it.
Do you see any possibility of some sort of "team effort" coordinated by TI to later be included on the utils library?
The "benefit" to my team would be the input of more experienced colleagues and an added formality given TI's "minimum quality" standards, but in the end it would be a win-win outcome for sure.
Regards
Bruno

Hi Bruno,
I have sent you a private message.

Hi Bruno,

Thank you for your reply

Regards
Sandra

Bruno Saraiva said:

I don't know if CCS can handle this Position Independent thing that Robert mentioned... but I would assume that one way or another, this indirect address shifting would require additional resources during execution. We decided not to learn it.

Not necessarily. What happens is that instead of addresses for constants (const int x; rather than 23) and functions being offset from zero they are offset from a different address. For some processors (the 'small & tiny x86 models for instance) this results in zero additional overhead, for others it's negligible. I understand the original MACs on the 68K processors used PIC. Note that the ARM instruction set does include a relative call so I wouldn't expect much, if any, additional overhead.

Whether CCS is good enough is a separate question. IAR can but apparently with some limitations.

Bruno Saraiva said:

Hence, what we do is to ALWAYS compile the main code to run from a fixed location configured in the .cmd file. An eventual firmware update is actually stored somewhere else, and during boot, if needed, the new firmware candidate is copied to the default location.

This will work provided the copy overhead on startup is acceptable.

In the event it is not, IE the requirements are

• No additional overhead on startup
• There must always be at least one valid tested in use binary to run at all times
  • After loading a new binary it must be possible to roll back to the previous working binary (marking the new binary as bad)
  • A new binary preferentially overwrites binaries marked as non-working, otherwise the user marks which valid binary to overwrite
    • This is in addition to checks for the binary being complete, accurate and from a reliable source, which should obviously mark the new binary as invalid.

In that case an alternative is to ship binaries located to two, or more, different positions and download only the binary that is for the position selected. A little more link and location work and larger distribution files but it otherwise behaves like position independent code.

Robert