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.
I trust the ulink tools in performing correct flashing, they are very expensive so they should do the job just fine. However, I want to make sure that even after years of field stress approaching max ambient T the ROM contents are still what they should be. But I do not only want to check them once a boot, because you can have a very long uptime. So system integrity verification is a separate task. Yes, I should have chosen a chip with flash corruption detection... imho the best effort to do this in software is to work on a full crc when there is free time and a quick check of the os kernel rom and/or most important regions as a more important continuous task. Checking full rom takes a long time...
Yes indeed manually might be a bad description. This is because my first thought was to have to code generate the checksum and have the debugger extract it and flash it in separate flash sector. But since most chips can have self program capabilities that would be unnecessarily difficult.
But my initial question is answered: Can keil scatterloading insert checksums per rom region? No, you must do this externally.
Thanks for your insights!
The build step just links, and no load is performed.
But when your program is booting, the startup code can perform scatter-loading of content from flash into RAM. This may include initialized variables but also copying of some code functions into RAM for faster execution.
Note that there are not really any "less important" part of the flash. One single bit of corruption within the code space can be enough to send the program flying anywhere - or to produce an incorrect result. So there really are no good reasons to sometimes only scan a limited part of the flash. Note that except for the bootup, it really doesn't matter much how long a flash scan takes. A flash scan can be performed piece-wise as time is available. So a number of ms of scanning at a time and maybe a final result after 10 minutes.
However, I want to make sure that even after years of field stress approaching max ambient T the ROM contents are still what they should be. But I do not only want to check them once a boot, because you can have a very long uptime.
That doesn't explain at all why you think you can't just checksum the hexfile vs. the flash contents, like basically everybody else in the history of embedded computing, and instead have to worry about the details of scatter loading.
Scatter loading is a process that copies stuff from ROM to RAM at startup. Either the un-scattered ROM contents were correct at startup, or they weren't. Once they've been copied, that part of ROM will never be touched again until the next reset, so it doesn't really matter if they're correct or not. And once that reset comes, you have no chance other than to try and use them, anyway, so what good would an answer of the form "Oh, BTW, your ROM image is now broken" do you?
And of course large parts of the RAM content generated by the scatter-load process is expected to change all the time as the program operates, so there is just no way checksumming it will have any remogely positive effect.
In short: forget about scattering. It just doesn't matter to the task at hand.
If you want to check the flash ROM contents, do that. The pristine master copy of that content is the hexfile generated by Keil tools, plus whatever post processing you decide to do. So checksum the hexfile, and patch the checksum right back into it.
As noted above, I think the term "scatter loading" is used by mistake, just because the linker takes a file using the scatter term. The flash image isn't scatter-loaded. The processor has one or more address ranges with flash content, and it isn't relevant to know exactly what things are placed where - the full flash content (potentially skipping remaining FF at end of the flash areas) should be checksummed since an application program isn't expected to understand exactly how the startup code might export data from flash into RAM.