Electronics > Microcontrollers

How many of you validate your I2C data in embedded systems?

(1/5) > >>

globoy:
I am prompted to ask this question by a recent failure mode where, very occasionally - say 1 in 2 million reads - an I2C read of a device returns invalid data.  The bad data leads the system to decide it needs to shut down.  Perhaps a fortunate outcome because otherwise I may have never known the corruption was occurring.

So I am curious what those of you who develop embedded systems do to validate I2C (or SPI accessed) control register data.  I know that usually it's easy to detect a failed transaction - a missing ACK or address decode or timeout - since the driver can report the failure.  But unless there is some sort of validation then corrupt data may make its way into the system.  Perhaps often it doesn't matter - for example a single bad battery voltage pushed into an averaging array probably won't negatively affect system operation.  But for cases like looking for a status bit that is clear-on-read then it can matter.

Most serial protocols, and most data storage systems, include data integrity support such as a checksum or error correcting codes, but most hardware control register interfaces do not.

Just curious what others do.

coppice:
Have you checked your signal integrity, especially under high EMI conditions? A well designed board should exchange I2C data continuously, with only the rarest of errors. If individual transfers are of high importance, like storing key data in an I2C EEPROM or FRAM, people tend to add a checksum to each stored block of bytes.

nctnico:
For sensors / analog inputs I typically use averaging. That also takes care of false readings. In some cases I ignore outliers. With sensors there can be many causes of false readings that aren't necessarily interface related but can also be caused by external interference.

When dealing with SPI / I2C based storage, I always have a checksum over the data (from a simple modulo 256 to SHA256 depending on the application). Typically I use a round robin system that wears an external memory evenly. So when a verify fails, I let the software use the next sector. This covers flash failures and communication failures.

There is also a third use case and that is controlling something external. My goto approach is to continuously update the output values so that if a write goes wrong, it is corrected quickly. A 10ms internal usually is enough because many mechanical actuators (like relays, valves, etc) need more time to react anyway.

edit: typo

David Hess:
For analog measurements I have sometimes calculated the standard deviation and peak-to-peak which could be used to reject bad readings or detect degradation.

For packetized communications between microcontrollers, I almost always use some form of error detection.  I do the same for stored data records.

globoy:
I have looked at signal integrity with a 200 MHz BW scope and it looks ok.  Have not correlated it with EMI but it's being tested and failing in the same location.

I have been doing some testing where I leave systems running and have them print out unexpected results. So far I've gotten two failures this way and in both cases extra (reserved 0) bits were set.  In my mind this reduces the possibility that, for example, the data being driven is too slow and is being sampled incorrectly since there should be long stretches of time where SDA is pulling the bus low.

Regarding checksums and the like.  Yup, exactly.  Things like storage or even streams of data can be - and usually are - protected with additional data.  But what to do with control registers?

Probably this particular problem has some acceptable work-arounds (I can validate the data and perhaps even recover from an errant shut down by immediately rebooting in that case).

But I'm a little embarrassed to admit for the last 15 years of doing embedded systems I've sort-of ignored this until it has come to bite me.  So now I'm curious what y'all do.

Navigation

[0] Message Index

[#] Next page