Validating Code Memory

I REALLY& feel sorry for you. You get the same answer (with differen verbage) in your cross post

(http://www.cygnal.org/ubb/Forum1/HTML/001619.html

Erik

I REALLY& feel sorry for you. You get the same answer (with differen verbage) in your cross post

(http://www.cygnal.org/ubb/Forum1/HTML/001619.html

Erik

how do you intend to handle the case when the corruption happens in your validation code

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.

The chances of a failure go up, because there's some extra failure paths in the validation code, but the chance of a undetected failure goes down.

Complete insanity of the validation logic would be handled by a watchdog timer.

Simple failure cases (e.g., the validation routine always returns TRUE) still have to be found by analysis, inspection, and test, alas. This motivates the designer to keep the validation test simple, so it's reasonably close to provably correct.

A more extreme case of the same test is a CPU diagnostic. The same question occurs -- how can you trust the CPU to test itself? -- but the answer is the same. You're really calculating a signature of some sort, and a broken CPU is unlikely to produce the correct signature.

"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/