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.
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.