cancel
Showing results for 
Search instead for 
Did you mean: 

Flash verification using CRC

oao
Associate II
Posted on November 21, 2010 at 15:51

Flash verification using CRC

7 REPLIES 7
oao
Associate II
Posted on May 17, 2011 at 14:15

Flash verification is one of several tests used to conform to the IEC60730 safety standard, e.g. for a washing machine controller. Your points are valid, but say that one bit of the flash has been altered, e.g. due to an ESD shock or old age. If the flash size is 64 k and the CRC function is 50 words long the probability of that error hitting the CRC function is small. Even though this should happen the error would be observed: if the fault is detected through a non-functional CRC function or a CRC error is not that important, in both cases the controller should be halted.   

Andrew Neil
Evangelist
Posted on May 17, 2011 at 14:15

''The program and data contained in a micro controller flash memory can become corrupted over time''

In theory, yes - but in practice, I think this is an extremely rare occurrence?

''The integrity can be verified by running a CRC test over the flash''

There is a fundamental flaw here: if you suspect that the Flash may be corrupted, then you cannot rely upon a program stored in Flash - can you?!
Andrew Neil
Evangelist
Posted on May 17, 2011 at 14:15

Unless the Flash has specific areas that are less-susceptible to errors, if any bit can be damaged in the flash, it is equally likely to be at any location - so it is equally likely to be within the CRC verification function as anywhere else!

''if the fault is detected through a non-functional CRC function''

That's the fundamental flaw: if the flash of the CRC function is corrupted, it doesn't just become a ''non-functional CRC function'' - it could do abolutely anything at all!!

''the controller should be halted''

Again, what if the error is in the part that halts the controller...?

domen23
Associate II
Posted on May 17, 2011 at 14:15

Neil, while I mostly agree... if the function is 256 B, and flash size 256 kB. And there's one bitflip... it's only 0.1% chance it's in that function (assuming uniform random distribution etc.). Not really foolproof, but it could be useful if you experience ''interesting'' things during development.

We used flash crc for firmware updates... to make sure data got transferred correctly over wireless, so we didn't boot invalid application.

With some lpc parts we've had interesting flash problems.. everything was fine, but bits started ''deteriorating''. In the end we found out that we used an incorrect clock while flashing. Crc checker as described here would probably make it faster to hunt down the problem in that case.
oao
Associate II
Posted on May 17, 2011 at 14:15

oao
Associate II
Posted on May 17, 2011 at 14:15

''Unless the Flash has specific areas that are less-susceptible to errors, if any bit can be damaged in the flash, it is equally likely to be at any location - so it is equally likely to be within the CRC verification function as anywhere else!''

The probability of a bit error is equal for all bits of the memory, but the probability of a bit error within the specified range of the CRC code is small. This is exactly how lotteries work.

''if the fault is detected through a non-functional CRC function''

''That's the fundamental flaw: if the flash of the CRC function is corrupted, it doesn't just become a ''non-functional CRC function'' - it could do abolutely anything at all!!''

Flash verification is only on part of a verification suite according to the standard. Other parts are in place to catch wild code execution.

''the controller should be halted''

''Again, what if the error is in the part that halts the controller...?''

 I don't quite see how verifying the flash has any impact on the halt functionality, unless of course you do not run any tests and therefore never find any reason to halt the controller.

I'm here because I pointed to code that may be useful for some of the forum members, not to discuss implementation of the IEC standard. If you have issues with the standard I advice you to go to a forum for that topic or even better, go to Google where I'm sure you can find some literature about this.  

Andrew Neil
Evangelist
Posted on May 17, 2011 at 14:15

''I don't quite see how verifying the flash has any impact on the halt functionality''

 

It doesn't.

My point is that, if a fault can occur in flash, it is as likely to occur in the halt functionality as anywhere else.

''I'm here because I pointed to code that may be useful for some of the forum members''

 

Actually, you posted to publicise an article in your blog which you opened by saying,

''The program and data contained in a micro controller flash memory can become corrupted over time. The integrity can be verified by running a CRC test over the flash.''

 

 

In the absence of any indication to the contrary, I took it that those were your own words?