8
\$\begingroup\$

Some error checking methods like parity check, checksum, CRC, etc. are used for wired/wireless communications. However, most of the ICs with interfaces like I2C, SPI, etc. don't use an error checking method.

Let's search for "i2c i/o expander" and open a random datasheet. For example, let's consider PCF8574 from TI which is a 8-bit I/O expander. If a bit corresponding to output register is flipped during I2C transmission, the IC will drive the corresponding pin to an undesired level. Why most of these kind of ICs don't have any error checking mechanism at all? My assumption is that even if communication is between ICs, all signals are noisy. Although the probability will be quite low, noise can cause a bit flip.

May this be the reason?: None of error checking mechanism gurantees a completely error free communication. They can only help us to reduce the probability of error. It is obvious that probability of bit error for long range communication is higher than on board communication. Maybe bit error probability for on board communication is in a acceptable range even without any error checking mechanism.

What do you think?

\$\endgroup\$
9
  • 3
    \$\begingroup\$ For the same reason a road doesn't provide cushion in case you crash. The road just provides the avenue to transport your car. You can put any safety equipment in your car you desire. Serial ports provide an avenue to transport bits of data. It's up to the designer to provide as much error and fault checking as is desired. \$\endgroup\$
    – Dan Laks
    Commented Jun 3, 2016 at 21:26
  • \$\begingroup\$ the speed you clock the bus at, and the voltage level used (i2c is open collector, you can use a wide range of voltages) significantly helps reduce possible error \$\endgroup\$
    – KyranF
    Commented Jun 3, 2016 at 21:28
  • \$\begingroup\$ If a bit corresponding to output register is flipped during I2C transmission, the IC will drive the corresponding pin to an undesired level. uh, what? \$\endgroup\$
    – Passerby
    Commented Jun 3, 2016 at 21:28
  • \$\begingroup\$ @Passerby he means, if you send a command to the I2C IO expander, to change the output states, if for some reason there is a condition where one of the bits that represents the output pin happens to have noise on it during the clocking cycle, the intended output will be different from what the IC actually puts out, thanks to the command byte over I2C having noise \$\endgroup\$
    – KyranF
    Commented Jun 3, 2016 at 21:31
  • 1
    \$\begingroup\$ @DanLaks I see your point. I can add error checking if I am designing the units which communicate over serial port. In I2C case, commands and protocol are fixed by IC vendor and they don't include any error checking in general. \$\endgroup\$
    – ayazar
    Commented Jun 3, 2016 at 21:42

7 Answers 7

11
\$\begingroup\$

You have to assume certain things just work, even in a world with error checking. Why pick on IIC or SPI when there are usually many more digital signals on a board? You seem to be OK with assuming those will all be interpreted as intended.

A properly designed circuit on a properly designed board should be reliable. Think of a CMOS output driving a CMOS input across a board. Other than outright component failure (which is a whole different problem from occasional data corruption), think about what can actually go wrong. At the driving end, you've got a FET with some maximum guaranteed on resistance connecting a line to either Vdd or ground. What exactly to you imagine can cause that not have the right level at the receiving end?

Initially the state can be undetermined as whatever capacitance on the line is charged or discharged. Then there can be ringing in the short trace. However, we can calculate maximum worst case times for all this to settle and the line to be reliably across some threshold at the other end.

Once this time has been reached and we've waited for whatever the worst case propagation delay of the logic is, there is little to change the signal. You may be thinking noise from other parts of the board can couple onto the signal. Yes, that can happen, but we can also design for that. The amount of noise in another part of the board is generally known. If not, then it's coming from elsewhere and in proper design it would be clamped to be limited to some maximum dV/dt and other characteristics. These things can all be designed for.

External noise can in theory upset traces on a board, but the field strength would need to be unreasonably large for a properly designed board. High noise environments do exist, but are limited to known locations. A board may not work 10 meters from a 10 kW transmitter, but even that can be designed for.

So the answer is basically that digital signals on the same board, if designed properly, can be considered absolutely reliable for most ordinary uses. In special cases where the cost of failure is very high, like space and some military applications, other strategies are used. These usually include redundant subsystems. You still consider individual signals on a board reliable, but assume boards or subsystems as a whole may occasionally err. Note also that these systems cost much more, and such a cost burden would make most ordinary systems, like personal computers for example, useless by being too expensive.

That all said, there are cases where even in ordinary consumer electronics error detection and correction is employed. This is usually because the process itself has a certain error probability and because limits are being pushed. High speed main memory for computers often do include extra bits for error detection and/or correction. It's cheaper to get the performance and ultimate error rate by pushing limits and adding resources to error correction than to slow things down and use more silicon to make everything inherently more reliable.

\$\endgroup\$
2
  • \$\begingroup\$ Thank you for long answer. I didn't consider a special case not to receive correct bit actually. My thought was much more simpler. I have used I2C I/O controllers in my applications to control something and I don't want to open a relay due to a single bit flip, let's say. Additive noise is everywhere (resistors, transistor, etc.), why doesn't cause a bit flip during communication.? \$\endgroup\$
    – ayazar
    Commented Aug 23, 2016 at 18:44
  • \$\begingroup\$ Noise is everywhere, but the desired case for circuits will be that noise is nowhere near of enough magnitude to flip a bit from high to low or vice versa at regular logic levels at the time a value is sampled, for any intra-device communication. If noise is that high, that's something you have the power to solve - within your device. For communication over unreliable or uncontrollable links with remote devices, you think about error detection, retries, etc then because you don't have so much control over noise in that environment \$\endgroup\$
    – tom r.
    Commented Mar 4, 2021 at 6:42
7
\$\begingroup\$

Especially for protocols that are not designed to be used over cables, a properly designed board won't have errors, and a poorly designed board won't work well with or without error checking. For example, glitches on an I2C bus with multiple slaves can permanently lock up the bus(*) unless the master has a driver that can pull SDA high even when slaves are trying to pull it low. Guarding against that would make the protocol slower, but if the bus is sufficiently free of glitches that such possible behavior is not considered a risk, there wouldn't be much need for error-checking logic in general.

(*) If a slave thinks it sees a start condition in the middle of a data byte being read from another device, and interprets the data being read out as starting a command that should read out a string of zeroes, then it would be possible for each of the slave devices to acknowledge data bytes sent to the other in such a way that at any given time at least one of the slaves would be holding down the bus.

\$\endgroup\$
3
  • \$\begingroup\$ See also: SMBus. \$\endgroup\$
    – The Photon
    Commented Jun 3, 2016 at 22:29
  • 1
    \$\begingroup\$ Comment: in general, a master cannot pull SDA high since its driven open-collector. Even if a master were to temporarily switch to push-pull output and drive high, you'd have a bus-fight with a low-driving slave, ending up up with an indeterminent state and possible chip damage. The correct way to try to clear the bus is to toggle SCL until the slaves release SDA, and then send (I believe) about 8more clocks. \$\endgroup\$
    – DoxyLover
    Commented Jun 4, 2016 at 4:51
  • 1
    \$\begingroup\$ @DoxyLover: If there are two or more slaves and they've got out of sync, one could have a situation where one slave pulls SDA low for eight out of nine cycles, and another pulls SDA low for a different eight out of nine cycles. No number of SCK pulses would fix the situation. If the master were connected to each slave independently via e.g. 100ohm resistor, and could pull SDA hard high while cycling SCK for nine pulses would probably fix the problem. Not a nice solution, but my main point is that one needs to avoid letting I2C get into that situation in the first place. \$\endgroup\$
    – supercat
    Commented Jun 4, 2016 at 13:16
3
\$\begingroup\$

Why do you ask that only regarding error checking?

How can you be sure that the start condition is interpreted correctly? On wireline or wireless communications, the start of frame is a very complex combinations of bits, while on RS-232 it is a simple high to low change, and on I2C a simple protocol violation.

My point is that not only error checking is different, but all the elements of the protocol are much, much simpler for on-the-board protocols than their counterparts for wireline and wireless communications. And the reason is that the probability of error is several orders lower than for wired/wireless communications.

\$\endgroup\$
1
  • \$\begingroup\$ ACK bit verifies the reception of the command, right? (What if ACK is flipped? goes forever...) Retransmission is another point of communication and it is acceptable for many application. Driving a pin to wrong level due to bit flip and insufficient error checking is much more critical then retransmision. \$\endgroup\$
    – ayazar
    Commented Aug 23, 2016 at 18:55
2
\$\begingroup\$

The short answer is that many devices at which I2C and SPI are aimed are low power devices with small instruction sets and limited program memory. The specs allow them to implemented in firmware with little overhead. If you have the horsepower, you can add as many layers as you need, but these layers would eliminate many small imbedded applications.

\$\endgroup\$
1
  • \$\begingroup\$ However I can't change the behaviour of the mentioned I2C I/O expander even if I connect to a quad core processor (horsepower). I can't add an extra error correction mechanism on top of that. \$\endgroup\$
    – ayazar
    Commented Aug 23, 2016 at 18:47
0
\$\begingroup\$

I could not provide an legid answer but some comparison. Network protocols need layers of mechanisms, doing all purpose at once is not a good idea, you don't have packet crc in PHY until MAC layer has detected the RF error in 802.11.

SPI and i2c all have synchronised clocking so error rate and communication conflicts in timing will be minimum, and hardware to implement them are considered scarce.

that's all i can think of.

\$\endgroup\$
0
\$\begingroup\$

Find a specific solution for a specific problem.

If you have 3 relays that require absolute reliability: Then measure the output of them with 3 digital inputs, a redundant confirmation system, tailored for your application.

If you went off and designed a custom communication protocol, to solve all reliability issues once and for all, you would be making a common design error; Straying from the specific requirements to become sidetracked in generalities.

\$\endgroup\$
0
\$\begingroup\$

First of all its important to remember that I2C stands for Integrated Circuit to Integrated Circuit communications. It was designed to run from chip to chip on a PC board. However with systems like the Raspberry Pi driving I2C connection over cables, the standard is not being used for what it was intended for, and the resulting signal degradation means transmission is going to be much more error prone. I'm reading this thread because I'm looking for clues on how to reduce I2C errors in my Raspberry Pi setup.

That said, every I2C compatible device on my bus does validate and generate CRCs to check for bus errors. What doesn't check for errors is the incoming I2C device driver in Linux, but you can easily find libraries online for C or Python to check the CRCs that come back. What I can tell you is that checking them was eye-opening because an alarming fraction of the data coming back was bad. Now, I just discard it and try reading the data again but the longer-term solution is to redesign my I2C system to have less distance/capacitance in it. I'm considering an I2C switch to isolate the devices on their own signal runs. Or switching to Modebus or CANbus which are more electrically robust (and a bit more expensive to use because devices are more expensive.)

Because of weaknesses in the standard stimulated by long signal runs, there are some errors like SDA being held down by a slave device that are irrecoverable using typical linux I2C drivers and can require a power cycle. To correct bus lockups on your Pi, you could change the I2C pins to general I/O pins and then reset the bus in software with the required 9 clocks at 400 KHz before changing them back to I2C function, but there are lots of gotchas for this including requiring C code to toggle the CLK pin fast enough for a reset. While I've seen this discussed online, I have yet to find any code for it, and am considering just writing it myself. Or bailing on I2C.

By the way, I think using I2C close to what it was intended for, such as connecting daughter cards onto a Pi, is pretty safe. I have not had any trouble with such designs.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.