Does the scatter loading file mechanism have some method of adding a checksum to a rom region? And, most of all, if this exist: Can the checksum be reproduced by the target? Doing this manually for each release firmware is possible, but not preferred.
There is the ElfDwt tool, but I cannot find the method used to create the checksum. And this only seems to apply to the vector table to have NXP bootloaders accept the code.
I'd like to continuously check the startup file .o integrity and a one time boot .ANY ROM check. This since the product is placed in some hotter environments, which can cause issues.
What does manually mean? Keil tools expect you to create post-link user functionality to sign/package the linker output in a form that uniquely suits your needs/requirements. Given that such operations are trivially easy to automate, I'm not sure I'd characterize that as manual, which would be where you went in and fixed something up with a hex editor by hand.
http://www.keil.com/forum/24722/
Manually, have the code generate its own checksums at first boot and write it to flash/eeprom. This does not cover existing flash errors, however unlikely.
I read there is no way to automate this for separate regions? But only for the full bin as explained somewhere in the faqs?
So, scattering does automatically load code to the right places, but cannot verify it succeeded?
"So, scattering does automatically load code to the right places, but cannot verify it succeeded?"
Not sure what you mean.
The scatter file is just a configuration file to tell the linker what memory to use and your policy for distributing the symbols. It has nothing with loading of a program into your device to do - it's the software that programs your chip that is responsible for doing a verify step after the transfer.
And if you work with a boot loader, it's your boot loader which is responsible for verifying that the checksum of a received binary is correct.
It isn't your linker that should try to figure out if a device that you sent out 5 years ago still has valid content in the flash, or if there have been any flash corruption. The poor linker can't do such things. It can't even understand if a local checksum algorithm in the device will even be possible to run if different corruptions has happened in the flash.
It's up to you to decide how to write code to perform to compute any flash checksum (or CRC or MD5 or whatever algorithm you decide on) during or after your processor has booted. And it is then up to you to adjust the build process so that the binary that gets produced during a build contains such a checksum, so your code has anything to compare with.
Keil can't do it for you, because Keil can't know where you want to store a checksum, or what type of checksum you want. Or when you want the checksum to be evaluated. All they can do, is allow you to insert one extra step in the build process, after the normal linking have been performed, where you can execute own programs and perform any post-processing of the binary. There are a number of threads on this forum that debates different alternatives to generate checksums during such a post-processing step.
Normally the code stays where it is, in ROM/FLASH, the data (statics) get copied to RAM, and other areas are zero.
Given that the region in ROM/FLASH is generally linear in nature, it makes sense to verify the integrity of that, it also shouldn't change during execution, so repeatedly checksumming/crcing it should resolve to the same value.
I know of the post-linker steps. However, for my application I would have to link twice. Maybe I need to look at a custom programming algoritm.
I meant the scatterloading code between the end of the startup.s and the jump to main. There the scatterloading process is executed. If you've defined RAM execution areas, the data is copied at this point.
I know now that there is no option for scatter-region separate checksums build in. And that I have to do this myself.
You'd need to link it twice why exactly?
The post link steps can decode the .HEX/.AXF outputs, process those into other .BIN, .HEX or .AXF alternatives, compute and add checksums, patch constants, etc.
The functions performed can be as simple, or as complex, as needed. All however require some basic file processing skills, and familiarity/comfort with managing binary data, and structures contained therein.
If you use a hex file as output, then you link twice, convert to hex and then modify the hex file to contain an extra line with the address of the checksum and the value of the checksum.
The hex file supports multiple flash address ranges, in case you have a processor where the flash doesn't represent a single linear block. And it also support holes, so if the binary only fills half the flash, then the hex file can skip over unused space in case you want to use the last 16 bytes for a checksum.
Manually, have the code generate its own checksums at first boot and write it to flash/eeprom. Setting aside the fact that that's a very strange meaning you apply to the word "manually" there, that's a rather bad idea.
About the most likely point of failure that checksumming is meant to protect against is communication distortion during the transmission of the flash image to the processor. Checksumming a corrupted flash image as valid is a bad failure. It is much better to perform the checksum directly on the generated program image (hex file or similar), before such failure mechanisms can strike.
I didn't know that hex files supported multiple ranges. I'll look into that. Being able to reserve a CRC area and have my own python script create crc and store it in that region might be an possibility.
View all questions in Keil forum