• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 21 subscribers
  • Views 3902 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Compute CRC of code with armlink

Christophe Ducommun

I'm starting to write a bootloader for my Cortex-M4 processor.

At start I need to check integrity of application in flash, for this I need the compute
the CRC of the content of the flash and compare with the correct one.

I want to know if it is possible to ask armlink to generate the CRC of the code (RO)
and add it to the binary at a specific location in flash.

The idea is to read this CRC generated by armlink (application) by the bootloader,
then compute the CRC of the content of the flash and then compare the two CRC.

Thanks
Christophe

Parents
  • 0 in reply to Christophe Ducommun

    But "the user" is a different usage case than when you are going to debug. That's a "production" case.

    Note that when debugging, you can directly bypass your boot loader and adjust the PC to directly activate your downloaded application.

    When you are debugging the boot loader, you can't really expect to also debug the application - you do not want the boot loader and your application to be built at the same time. The boot loader is a completely separate application that should either have a separate project or be built as a separate target in your project file. And if you debut the boot loader, then you have other options for generating the binary file that you want the boot loader to download.

    So in the end, I don't see why you need an elf file with additional CRC - your boot loader will not expect elf files. And if you aren't debugging the download process, then it doesn't matter exactly how the application got programmed. So it's ok to use a hex or bin file with additional CRC.

Reply
  • 0 in reply to Christophe Ducommun

    But "the user" is a different usage case than when you are going to debug. That's a "production" case.

    Note that when debugging, you can directly bypass your boot loader and adjust the PC to directly activate your downloaded application.

    When you are debugging the boot loader, you can't really expect to also debug the application - you do not want the boot loader and your application to be built at the same time. The boot loader is a completely separate application that should either have a separate project or be built as a separate target in your project file. And if you debut the boot loader, then you have other options for generating the binary file that you want the boot loader to download.

    So in the end, I don't see why you need an elf file with additional CRC - your boot loader will not expect elf files. And if you aren't debugging the download process, then it doesn't matter exactly how the application got programmed. So it's ok to use a hex or bin file with additional CRC.

Children
  • 0 in reply to ImPer Westermark

    I'm a pretty proficient coder, and can process ELF/AXF files. The tools Keil provides can get you to a HEX or BIN, but in most cases OTA type files need to be packaged specially anyway (compressed, encrypted, signed, etc). As Per observes for debugging where the U-Link, et al, injects code I usually just place a marker in the vector table to indicate this is a debug build, and the bootloader is smart enough to recognize that. The bootloader is what burns the OTA image, not the JTAG interface.