Compute CRC of code with armlink

Thanks for the response,

Can you give me more information where I can found some documentation, tutorial or anything
else for doing this ?

Thanks for the response,

Can you give me more information where I can found some documentation, tutorial or anything
else for doing this ?

http://www.keil.com/support/man/docs/uv4/uv4_dg_user.htm

I usually just code a simple file IO application that can read a .HEX or .BIN and add the CRC or checksum at the back end.

OK it's not a problem from me to write a simple exe for adding the CRC at the end of the image.

But armlink produce an AXF file, and after that Keil flash the code from this AXF in the flash.

There is a tool (fromelf) to read or convert AXF file. But I don't really know what is the best thing to do.

Because I want to have this CRC in the flash when I use the debugguer and flash the binary when I start the debugguer.

Do you read the AXF file from your IO application, or do you configure armlink to produce the binary or hex file ?

How do you ask armlink to produce the bin or hex file ?

And then how do you flash the modified file before starting the debugguer ?

Thanks

I never worry about these steps if I'm going to debug anything.

Any CRC is for OTA or production files, where I normally ship in hex format to the factory, and use an augmented bin file for over-the-air updates.

If I'm going to debug, then I don't care about having a boot loader scan any integrity of the application. And the application itself can compute it's own CRC and inform me if I want to know.

If the user download a new version of the software and there is something going wrong during download, the application is not fully downloaded into flash and the bootloader need to detect this. Because if the bootloader start an invalid app in the flash it will not start or work as expected.

If think it's not a good idea to compute the CRC of the app in the app application.

For example the TI linker compute the CRC and add this CRC in the binary. Then the bootloader can read this CRC and compare with the computed one from the flash.

If the two CRC are the same, the bootloader can start the application, or enter in download mode if there is an invalid image in flash.

I think it's the best approach to have a fail save download. In order to debug the bootloader and app image map, I need to have the CRC flashed with the app.

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.

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.