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.
View all questions in Keil forum