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 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.
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.
However, for my application I would have to link twice. I'll second the question: why on earth do you think that you have to do that?
Maybe I need to look at a custom programming algoritm. Same here: why?
Maybe what you really need to do is take several steps back from the frontier of your problem and tell us what exactly it is you're doing. You're seeing problems that, IIRC, nobody else on this forum ever mentioned. So you must be doing something very differently from everybody else. Maybe you took a wrong turn several steps back, or seriously misunderstood some requirement even before that.