ROM Region checksum

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?

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.

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.

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.