# Why don't on board communications like I2C, SPI, etc. have error checking in general?

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?

• 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. – Dan Laks Jun 3 '16 at 21:26
• 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 – KyranF Jun 3 '16 at 21:28
• 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? – Passerby Jun 3 '16 at 21:28
• @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 – KyranF Jun 3 '16 at 21:31
• @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. – Alper Jun 3 '16 at 21:42

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.

• 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.? – Alper Aug 23 '16 at 18:44

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.

• See also: SMBus. – The Photon Jun 3 '16 at 22:29
• 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. – DoxyLover Jun 4 '16 at 4:51
• @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. – supercat Jun 4 '16 at 13:16

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.

• 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. – Alper Aug 23 '16 at 18:55

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.

• 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. – Alper Aug 23 '16 at 18:47

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.

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.