• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 362 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.

TM4C1294NCPDT: In-Application programming

Abhijit Acharekar
Intellectual 650 points

Part Number: TM4C1294NCPDT

Hello Team,

In order to support in-application programming, we are using a flag (32 bits) which we write to the last location in the FLASH. While application is running, a request to flash programming will update this flag to a unique value and then we switch to bootloader. Since the flash supports a  block erase and a  block write. We need to maintain a buffer of 16k, to take a back up of last block and overwrite only the flag memory. For this either we can occupy the stack or heap. But can we avoid this? Is there any alternative other than using Eeprom?

Thanks

Abhijit

  • 0
    TI__Guru*** 135355 points

    Hello Abhijit,

    Is the purpose of the flag to ensure there is a valid image then? Would doing a CRC check of the new application work in that regard?

    It sounds like the way you have set this up would be to update the flag with the value ahead of time, and then compare the flag value after boot loading to the new one. Is that correct?

    Maybe this feature would give you what you need, or offer another idea for the placement of your flag:

    CHECK_CRC

    Enables runtime CRC checking in the boot loader. If this label is not defined, the boot loader will transfer control to a main application image if the initial stack pointer and reset vector of the image appear to be valid in flash. No additional checking is performed. When this label is defined, however, the firmware image’s CRC32 value is checked against a value stored in a header at the top of the image’s vector table and the firmware is only booted if the calculated CRC matches the value in the header. If the header is absent or the calculated CRC does not match the expected value, the boot loader retains control and waits for a new firmware image to be downloaded. As a special case to aid debugging, the image will be booted if the header is found and the length field is set to 0xFFFFFFFF, regardless of the value of the CRC32 field. This debug behavior can be disabled by also defining ENFORCE_CRC. To use the CHECK_CRC option, firmware images must be built with an 8 word header appended at the top of the interrupt vector table. This header must have the first 4 words populated as follow:

    • Word 0: 0xFF01FF02
    • Word 1: 0xFF02FF03
    • Word 2: Length of the firmware binary image in bytes.
    • Word 3: CRC32 calculated over entire image except for the 4 bytes occupied by this word. The CRC calculation includes the header marker words and the length word.

    The remaining 4 words in the header are reserved for future extensions and should be set to 0xFFFFFFF. This header should be added by reserving 8 additional words above all the required entries in the project’s vector table (typically in the startup C or assembler file depending upon the toolchain in use) and initializing the first two to be the required marker words and the remainder to value 0xFFFFFFFF. The length and CRC32 value can be inserted by passing the firmware binary as the input to the binpack.exe tool found in the tools directory of your TivaWare release.

    My thoughts reading over your requirement is that the above process should be a suitable method to secure the firmware image.

    Regarding maintaining a buffer of the last block, the Flash boot loader actually executes out of RAM, so I would imagine using RAM would be the easiest method to do what you are describing unless you think that you are too tight in program space to make that work. However, I am not certain how you plan to actually fetch all of that Flash data? Would it just be a custom function to manually read and store each byte? I would think the CRC method offered above would be easier to use and provide the same level of security.

  • 0 in reply to Ralph Jacobi
    Intellectual 650 points

    Hi Ralph,

    Sorry for late reply as I was busy with some other work.

    We have written our own bootloader. The FLAG in the flash will be used by bootloader to decide to remain in bootloader or switch to application.

    I need some more time to digest your response.

    Thanks & Regards

    Abhijit