I should really like I2C more than I do. In principle, it’s a brilliant protocol, and in comparison to asynchronous serial and SPI, it’s very well defined and clearly standardized. On paper, up to 127 devices can be connected together using just two wires (and ground). There’s an allowance for multiple clock-masters on the same bus, and a way for slaves to signal that the master to wait. It sounds perfect.
In reality, the tradeoff for using only two wires is a significantly complicated signalling and addressing system that brings both pitfalls and opportunities for debugging. Although I2C does reduce the number of signal wires you need, it gets dangerous when you have more than a handful of devices on the same pair of wires, and you’re lucky when they all conform to the same standard. I’ve never seen twenty devices on a bus, much less 127.
But still, I2C has its place. I2C was designed to connect up a bunch of slower, cheaper devices without using a lot of copper real estate compared to its closest rival protocol: SPI. If you need to connect a few cheap temperature sensors to a microcontroller (and their bus addresses don’t clash) I2C is a great choice. So here’s a guide to making it work when it’s not working.
Let’s start off by looking at the wires, because that’s where a surprising number of glitches and complications can creep in. Whereas SPI gets by with the minimal amount of protocol overhead but pays the price in a florescence of wires, I2C only requires you to lay down two tracks: one for the clock (SCK) and one for data (SDA). There is a price for this simplicity when interfacing systems that run at different voltages.
I2C devices can also be constructed with a single transistor per line, because the two lines are pulled up by an external resistor (or resistors). This sounds good, but can cause problems with high-speed signals and high-capacitance lines.
So let’s get down to details.
Pullup Resistor vs. Parasitic Capacitance
The problem with relying on pullup resistors is “parasitic capacitance”. While we normally think of a capacitor as being made of two large conductive plates with a dialectric (or air) between them, the same charge-storage capacity exists between two parallel wires as well. And this means that there’s some small capacitance between the I2C signal lines and the PCB’s ground plane, or any other adjacent signals for that matter.
This parasitic capacitance means that the voltage level on the signal line (data or clock) can’t change instantaneously, but some finite current needs to be pumped into the wire to charge up this accidental capacitor. With SPI and asynchronous serial, this is not much of a concern because the high and low voltage levels are both driven by transistors on board the chips in question. Parasitic capacitance matters a lot in I2C because the devices pull down the signal lines, but they’re pulled back up by resistors (or a constant-current source in higher-performance designs).
This means that, while a high-to-low transition can be next to instantaneous, a low-to-high transition will always take some time as the line charges back up. This means that the signal lines can’t be too long, to keep parasitic capacitance at bay. 400 picofarads is the maximum, according to the standard. The optimal choice of pullup resistor varies with line capacitance, desired speed, and the strength of the transistors in the various devices, but 4.7 kOhms is normal.
Here’s some up-close shots of an I2C conversation. (We’ll discuss the protocol below.) Note that the downward transitions are nearly instantaneous, but it takes some time to rise back up to VCC. If these transitions needed to be faster, a smaller resistor could be used for the pullup, with increased power consumption in the bus being the negative side-effect.
See those tiny up and down spikes on the data line that occur in time with the clock (and vice-versa)? That’s the effect of another parasitic capacitance that couples the clock and data lines together. It’s not enough to change any of the digital values, and it decays back down pretty quickly, but in a more extreme form this could cause problems too.
Keeping the lines short and minimally coupled to each other and their surroundings is the cure. If you’re running other data lines over/under the I2C lines, arrange for them to cross seldom, and at 90-degree angles. A long wire with a weak resistive pullup is almost as good as an antenna.
Bidirectional — Voltage Level Conversion
The data line (
SDA) is necessarily bidirectional: both the master and the slave ICs have to read its voltage. But when you’ve got chips that work at different voltages, the line has to be pulled up to a high voltage on one side, and a lower voltage on the other.
Fortunately, there’s an application note for that (PDF). The standard solution is to use one MOSFET per line and abuse the intrinsic body diodes to pass signals through from the high side to the low side. It’s a nice hack, and you’ll enjoy reading it. You can buy these simple converters pre-made from most hobbyist-friendly shops, or directly from the Far East.
So far, I2C sounds only a little bit tricky, but the truly tricky bits all take place at the protocol level. To start out, the data line is always set up when the clock line is low, and can be read out any time the clock line is high. (This definition eliminates the phase/polarity issue with SPI, and the voltage-inversion problems with async serial.) There are two exceptions to this rule: if the data line transitions high to low with the clock high, it’s a start signal, and if data transitions high during a high clock, it’s a stop. Every transaction starts with a start signal and ends with a stop. This, in principle, lets every device on the line know when a conversation is underway, and tells them not to begin a conversation of their own until they see a stop.
Because all of the devices share the same two wires, they need addresses. Additionally, the slave devices need to know whether they’re supposed to send or receive data on the single wire. The first byte of any transaction, after the start signal, is a seven-bit address and a single direction bit that tells the slave whether it’s expected to read or write data. For instance, with an LM75 temperature sensor, you can read the two-byte temperature value by sending the device’s address ($48 in this example) combined with the last bit set to one — to read the data. The master then sends two bytes worth of clocks, during which it receives the data, and then sends the stop signal. Well, with one more complication.
Every byte sent on the I2C line is acknowledged (positively or negatively) by the party (slave or master) that just received the last byte. It’s purpose is for the device to say “OK, I got that, go on”. So when the master is reading bytes from the slave, the master acknowledges each one before the next byte is sent. If the master is writing bytes to the slave, it’s the slave that has to acknowledge. A low voltage level, pulling the data line down, is the positive
ACK signal, and it means that everything’s alright.
Things are more complicated with the negative-acknowledge (
NACK) signal. Depending on context, it can mean “I’m not ready” or “that didn’t make sense” or even “I’m done receiving now”. Because of this multitude of possible meanings, one has to read the data sheet carefully to see when reading data from slaves because the master needs to know when to
ACK and when to
For instance, with the LM75 temperature sensor in its easiest mode, the master sends the address and a read bit, and then reads two bytes back. Since the master sent the address, the slave acknowledges to say it’s ready. Then the slave sends a byte, which the master acknowledges with an
ACK. Then the slave sends the second byte, to which the master responds with a
NACK and a stop signal to say it’s done.
Master: Start Signal Master: Address + Read Bit Slave: ACK Slave: First byte of data Master: ACK Slave: Second / last byte of data Master: NACK Master: Stop Signal
Wrapping up the protocol, there’s also multi-part communications. If the master needs to send a byte to the slave, and then read some bytes back, for example, it needs to first send the address with a write signal and then re-send the address with the read signal. To signal the change of mode, the master sends the so-called “repeated start” signal, which is just a regular start signal when there’s been no preceding stop. Again, here’s an example with the LM75, first telling the LM75 that is wishes to read the high temperature setting, and then reading the two bytes back.
Master: Start Signal Master: Address + Write Bit Slave: ACK Master: Set the high-temperature register for reading Slave: ACK Master: (Re-) Start Signal Master: Address + Read Bit Slave: ACK Slave: First byte of data Master: ACK Slave: Second / last byte of data Master: NACK Master: Stop Signal
Note that in both of these examples, when the master is reading an arbitrary amount of data from the slave, the last byte is “acknowledged” with a
NACK. This doesn’t mean that it missed a byte, but instead signals the slave that it won’t be requesting any more data. It’s an “all done!” signal. If you’re having trouble with the second transmission after power-on, have a look that you’re
NACKing at the end, otherwise the slave can get confused.
This whole business with
NACK can get tricky, and it’s definitely one source of bugs. On the other hand, the acknowledge bit provides a bit of information (tee-hee!) about how the communication is going.
The first thing to do when debugging an I2C system at the protocol level is to make sure that the slave device is there and listening. Since the slave is supposed to respond with an ACK after hearing its address on the data line, this can be used to scope it out. This should be your first stop in debugging an I2C setup: if the slave doesn’t even acknowledge its address, you’ve probably got wiring troubles.
Because there are only 127 possible addresses on a regular I2C bus, this can be generalized to check all the devices on the bus. An I2C bus scan simply goes through each address, and prints out which addresses lead to an
ACK. This is a great check to verify that each device’s address is what you think it should be. A bus scan and verification probably belongs in the power-on self-test of any serious I2C system. Modern I2C chips also have a chip ID field that can be read out. Use ’em if you got ’em.
I’ll be the first to admit, I usually throw away the
ACK bits when all is working well. When an I2C setup is behaving, it just wastes CPU cycles to test it with every byte. When things aren’t working, on the other hand, the
ACKs are a treasure. Tracing through a non-working multi-byte communication by reading the
ACKs lets you know when things went south.
If you’re using an AVR chip, have a look at the datasheet for their “two-wire interface” (which is I2C, but doesn’t infringe on Philips/NXT’s trademark name). The hardware I2C module has a status code for almost every step along the way, including testing for expected
ACKs and more. I’m sure other chips do something similar. If you’re having troubles, check status codes after each byte and compare it with the signal diagrams in the device’s datasheet. You’ll get it straightened out.
Odds and Ends
I2C, as described so far, is pretty complicated, with a lot of hoops to jump through and opportunities for bugs to creep in. It gets worse.
While it sounds cool to have an address space that’s able to accommodate up to 127 devices, the reality is that any I2C bus will probably only have a handful connected up. There are two reasons for this. The first is that each device added to the bus brings along a little parasitic capacitance. The second is that device addresses aren’t fully flexible, and they can even conflict across different ICs.
To take the LM75 example again, all of the chips have a hard-coded base address of hexadecimal
0x48 when they come from the factory. They also have three pins that, when grounded or pulled up to the supply voltage, let one specify up to eight possible addresses by adding the binary value of the three lines to
0x48. This means that you can only have eight LM75s on your bus at a time. Period. Not 127.
And you can’t use different chips if their addresses overlap, either. NXP’s PCF8563 RTC chip has a read and write address, both of which conflict with two of the eight addresses selectable for a 24C32 EEPROM, for instance. Many years ago, Adafruit started keeping track of these addresses and making a master list. Unfortunately, it looks like they gave up a long time ago as well. You’re on your own to read the datasheets and avoid address collisions.
A possible solution to the addressing problem is extended 10-bit addressing, which was adopted as a standard in 1992, but I still don’t see all that many devices using it. (Maybe it’s me.) The scheme uses a fixed 5-bit prefix (
0b11110) followed by two address bits and the read/write bit in the first byte, and then a second byte with the remaining eight bits of the address. 1,024 addresses should be enough for the entire universe of I2C devices, right?
Multi-mastering and Clock Stretching
This is where things get really hairy. Because of the pull-down, float-up behavior of the I2C signal lines, it’s electrically possible for two devices to send opposite signals at the same time. (The low wins.) This, in principle, can be used to extend functionality in two different directions. If a device expects to be sending a high signal on either
SDA, but the line is being pulled low by another device, something is afoot.
If a slave is pulling the clock down, it’s called “clock-stretching” and is a signal to the master to pause until the slave is ready. In principle, the master shouldn’t send until it notices the slave has released the line, and it floats back up. Of course this relies on the master checking for a low signal when it thinks it’s letting the line float high. If you’re using a reputable microcontroller’s I2C hardware, you’re probably in good shape — it will check the clock line. If you’re using some back-alley bit-banging I2C routines that won’t pause when requested, you’re going to lose data.
A more subtle problem can occur when the line simply stalls due to clock stretching. In principle, any slave device can stretch the clock by pulling it low, and they can do so for an indefinite amount of time, and the master must respect this and not send new data until the slave releases the clock line. This can wreak havoc with data on the bus that needs to get out on a schedule, in the best of cases. In the worst case, the entire bus can be effectively DOS’ed simply by pulling the clock line low.
Devices like EEPROMS or flash memories are notorious clock stretchers. They often write data in pages, and writing the data takes a finite amount of time. So they’ll take in 64 bytes (for instance) as fast as you can transfer them, but then they’ll stall when they hit a page boundary and need to write out. Watch out for these chips! Other EEPROMS have double buffers that essentially sidestep this problem, reading into one while they write out the other.
The I2C standard allows for multiple clock-masters to take turns on the bus. Ideally, every potential master is keeping track of start and stop signals. When the line is free, it can start its transmission. But what happens when two masters decide to start at once?
They “arbitrate”. If a master tests the line when it’s supposed to be high, and finds it to be low, it’s a sign that the line isn’t free after all. All devices that currently aren’t pulling the line down should stop their transmission. The idea is that before the address is finished, all the conflicting masters should have backed down. Needless to say, mixing devices that are and aren’t multi-master capable is a recipe for disaster.
Call me a coward if you will, but my solution to multi-mastering and clock-stretching issues is to avoid them. And that means using multiple I2C bus networks. By far the simplest way to do so is to buy a microcontroller that has more than one hardware I2C controller built in.
Adding a second I2C bus can also help isolate a rogue clock-stretcher that blocks other, time-critical, transmissions. Reserve one bus for the low-latency transmissions, and segregate the clock-stretchers to their own bus. Or if you’re running a mix of chips — some that only run at 100 kHz while others run at 400 kHz or higher — running a fast bus and slow bus will allow you to get the maximum speed out without confusing the slow ones. More busses means more flexibility.
But if you really need to go overboard and control a bazillion I2C devices with the same address on a single bus, the solution is an I2C multiplexer. These are special chips let you run, say, 16 devices with the same address from a single I2C port by selecting among them using some more lines from the CPU. This is a special situation, for special snowflakes.
So as you can see, there’s a lot going on with I2C, and a lot to go wrong. I2C debugging does not compare with raindrops on roses or whiskers on kittens.
- Go make yourself a calming tea or other beverage before you start.
- Double-check wiring. Are
SDAmixed up? Are voltage levels right/same?
- Are you running the bus at the right speed for the slowest slave? And are the pullups strong enough? Verify the speed and waveform shapes with a scope.
- Can you get the initial
ACKfrom your target device? Do a bus scan.
- Still failing? Pull all but your target device off the bus and get the initial
ACKworking. Add other devices back on one by one. This helps find bus-hogs.
- Once you get the initial
ACKworking, use these to step through the rest of the transaction, verifying one byte at a time.
- Are you setting the read/write mode correctly for each transaction?
- Are all parties
NACKing when they should? Sometimes you’ll see a glitch between the master releasing the line and the slave asserting a
NACK. This is normal, and actually a sign that all’s well.
- If you switch read/write directions, are you sending a restart and the address again? Does the device support this?
- Double-check address clashes in the datasheets. Scan the bus and make sure that you see the right number of devices.
- Are you multi-mastering the bus? Can you avoid doing so easily?
- If you need to troubleshoot a truly tricky problem, put different-value resistors on the output of all chips on the bus. The low voltage values will be slightly different for each chip, allowing you to see on a scope which chip is talking at any given time, and diagnose when they’re talking over each other.
Good luck with I2C! And let us all know in the comments if you’ve got any other specific troubles or solutions. We got some great responses for the other two articles.