Validating Code Memory

"As long as you're willing to accept a failure due to corruption of the validation code, it doesn't matter. Either the code executes correctly, and it detects the CRC error, or the validation code itself is corrupt, in which case it is highly unlikely to accidentally calculate the correct CRC."

True.

But if the validation code itself is corrupted, it most likely won't just do the validation incorrectly - it's behaviour will become entirely undefined!
It could do anything - jump off to random locations, etc, etc.

The point being, a checksum check alone (OP didn't even say CRC) is not a complete validation - you need to include other protections, like Watchdogs, etc.

"As long as you're willing to accept a failure due to corruption of the validation code, it doesn't matter. Either the code executes correctly, and it detects the CRC error, or the validation code itself is corrupt, in which case it is highly unlikely to accidentally calculate the correct CRC."

True.

But if the validation code itself is corrupted, it most likely won't just do the validation incorrectly - it's behaviour will become entirely undefined!
It could do anything - jump off to random locations, etc, etc.

The point being, a checksum check alone (OP didn't even say CRC) is not a complete validation - you need to include other protections, like Watchdogs, etc.

In my opinion, code store validation was very much needed when we used ferrite beads. This practice has lingered ever since. Since I doubt this app is using ferrite beads for memory, I ask again WHY?

Erik

For ISP code it is a good idea. It insures a good write, and that the load was completed.

It may help at the end of Flash data retention. Some are as low as 10 years.

In my old UV EPROM code I never had a Checksum failure.

But of course It is not perfect protection.

Hi Erik,
Since the project is releted to medical application,the design intends to make a series of preliminary checks and one among this is to validate the code memory. Design just attempts to reduce failure rate during POST.

For ISP code it is a good idea. It insures a good write
not necessarily, it "insures a write" with flash you can do a "quick" write, read back and miss the data next day.

Obviously, if you use mamufacturer supplied routines correctly (I tend to recall a post saying specifying the wrong frequency to the IAP routines "made the programming go faster") there should be no concern of the solidity of the write.

Erik

OK, I know, that some medical standards require useless checks and do not require useful checks (remember the failing shield that killed several).

When such requirements exist, of corse, you have no choice.

so, remember that all erased memory read FF and just checksum to the end.

most important after implementing required safeties, go through everything and say "what happens if this fails", "what happens if that fails"...

It does not help to test the uC before you start if someone get harmed if it fails after the start.

Erik

I trust that you also have procedures in place to assure the quality of your source code; eg,

* MISRA, or other coding standards;

* Design & Code Reviews;

* Use Lint;

etc, etc,...

"... the project is releted to medical application ..."

http://www.validatedsoftware.com/