Is it okay to have multiple I2C devices on the same bus with the same address? - Page 1
Forum section: electronics / projects

author: Starlord
author_rank: Frequent Contributor
timestamp: May 29, 2016, 06:18:12 pm
content: I know what you're wondering... How would I send data to one or the other if they have the same address?The answer is: I don't need to!I have an LED driver chip which uses 0x00 as its default I2C address and if you send it a code it will switch over to whatever your solder jumpers are. I hear that's non-standard but that's the way the chip is.So in my testing, I have been encountering some lockups and I was just wondering if maybe that could be due to sending the same data to four different I2C chips at the same time on the same address? Do they send data back regardless of whether I specifically request it or something? I know about clock stretching too and I wonder about whether that might be the cause of the issue.I actually fixed the lockups with a timeout period but the chips turn off instead after a longer period of time which leads me to believe there's some data corruption happening.Anyway I don't want to know how to modify my electronics, I just want to know from a data transmission standpoint if these multiple ICs on the same address could be the issue. I would test unique addresses but I don't want to mess up my boards if I can help it.

author: linux-works
author_rank: Super Contributor
timestamp: May 29, 2016, 06:24:09 pm
content: it can work, but its still wrongI did that once. I wanted to address multiple things at once and they happened to be the same addr and were the same protocol (pcf8574 port expanders). they 'overlapped' ok and it was functional but I knew it was still wrong and could break at any time.for me, I needed concurrency, so that one command would be actioned at the same exact time for all slaves. for that, it did what I needed, but I would find another way to do such things.

author: Fungus
author_rank: Super Contributor
timestamp: May 30, 2016, 06:45:55 am
content: Quote from: Starlord on May 29, 2016, 06:18:12 pmNo.Quote from: Starlord on May 29, 2016, 06:18:12 pmI don't see how (so long as the master is responding correctly).

author: timb
author_rank: Super Contributor
timestamp: May 30, 2016, 09:57:21 am
content: Quote from: Fungus on May 30, 2016, 06:45:55 amWell, that's not entirely true. Each device does need to ACK or NACK after it receives data. However, if you have multiple devices with the same address all on the same bus, it could cause an issue. Some slaves can cause the bus to latch up if they should have control, but don't (or can't). Yes, I realize I2C is an open drain interface, that still doesn't stop these issues from cropping up.

author: Fungus
author_rank: Super Contributor
timestamp: May 30, 2016, 10:20:18 am
content: Quote from: timb on May 30, 2016, 09:57:21 amThat's not 'data' though.Quote from: timb on May 30, 2016, 09:57:21 amMultiple devices asserting ACK simultaneously shouldn't be a problem.I don't see how it could lock up the bus.I'd have a good look at the pullup resistors. It might simply be a case of the pullups being too weak for multiple devices (or being badly placed on the bus). One missed clock pulse by one of the devices would explain the symptoms.OP: If you have an oscilloscope then grab it and take a look at the bus signals. Make sure they're nice and square (and make it all the way up to Vcc for a decent length of time).If you don't: Try smaller value pullup resistors, or put another set of pullup resistors near the end of the chain.

author: timb
author_rank: Super Contributor
timestamp: May 30, 2016, 10:42:06 am
content: I've seen it lock up a bus before, however the devices in question were "dual-protocol" chips that could switch from SPI to I2C by tying a pin high or low. The I2C clock and data pins also served as MISO and MOSI and I suspect that caused the issue. (The pins weren't true open drain, instead being push-pull or internal resistive pull-up.) Switching to a comparable part designed exclusively for I2C fixed that particular issue.Anyway, even with an I2C only device, I could see a problem if the parts are scattered over a large area, or down a long cable drop. In that case, the closest device to the master would ACK first, but if the furthest device is more than a clock cycle away, it would hold the ACK longer than needed, which could cause an issue. Though, most I2C masters should handle the above scenario without the bus locking up (though, depending on how long the line is held, it might interpret it as an error and try again).Or, maybe you're right and he needs better resistors: If you had a lot of capacitance on the data bus and the pull-ups were too weak, it could certainly cause this sort of issue!That said, the official I2C specification doesn't have provisions for multiple slaves with the same address on the same bus, so there's no guarantee it will work in all cases. It very much depends on the devices, layout, number of slaves and so on. The proper way to do this is with an I2C Hub.

author: Fungus
author_rank: Super Contributor
timestamp: May 30, 2016, 10:51:01 am
content: Quote from: timb on May 30, 2016, 10:42:06 amThe only thing I can think of that would lock the bus is if one of the chips gets out of sync.Longer/shorter ACK pulses by different chips shouldn't matter. The master will just see it as clock stretching.(Assuming the master is behaving correctly and waiting for bus release after the ACK cycle)

author: timb
author_rank: Super Contributor
timestamp: May 30, 2016, 11:01:45 am
content: Quote from: Fungus on May 30, 2016, 10:51:01 amRight, but not all masters support clock stretching though! For example, there's a popular PIC micro which, due to a silicon bug, doesn't support it on the hardware I2C controller. Pre-1.0 releases of the official Arduino library had issues with it. A line of ST ARM parts doesn't support it at 400kHz due to a bug. The first revision of the RPi had problems with it due to a kernel driver problem. A lot of bit-bang I2C libraries flat out don't support it.Heck, I've seen several peripheral (slave) ICs that don't support it.I'm just saying it's not out of the realm of possibility that it could be the issue.

author: Fungus
author_rank: Super Contributor
timestamp: May 30, 2016, 11:28:42 am
content: Quote from: timb on May 30, 2016, 11:01:45 amSure, but in that case it could fail with a single chip too.

author: Starlord
author_rank: Frequent Contributor
timestamp: May 30, 2016, 12:53:49 pm
content: Quote from: Fungus on May 30, 2016, 10:20:18 amHow is an ACK or NACK not data? Does sending one require the chip to pull the data line low? And is it synced in some way with the clock line? If so, I would call that data.Regardless of what you want to call it, whether it is data or not is irrelevant. All I want to know is if multiple chips are pulling the data and/or clock lines low when I transmit commands to them, and if this is somehow corrupting the data, or state, or whatever you want to call it, and causing my firmware to lock up. In other words, if my firmware has a while loop that waits for the I2C bus to signal the transmission is complete, is it possible multiple devices with the same address could cause this signal, whatever it is, to never be detected?It seems like the answer may be yes, but I'm not sure what's going on on the bus, I can't say for certain. But what I do know is that the more devices I connect, the faster they error out. A single device will lock up after a while, but four on the same address will lock up almost immediately.If I add a time out to the code that waits for the transmission to complete successfully, a single device will run for an hour or so without issue. Multiple devices on the other hand will function for longer, but they still eventually drop out and stop responding. But at least the rest of my code continues to function with the timeout in place. Today I'm going to modify the code so it resets all the registers in the LED drivers each time it updates them, and hopefully that will resolve the problem.But what I'm really curious about here is whether or not this problem is being caused by my I2C bus lines being too long and/or the devices drawing too much current, or if it is a problem inherent to I2C when putting multiple devices with the same bus. Unfortunately, I don't have a scope yet to put on the lines to look at what's going on, but I don't need to if someone else has encountered this issue before and can tell me that yes, multiple devices with the same address will corrupt the data transmissions.QuoteMy I2C bus is being transmitted over 7' of twisted pair CAT5 and then through 6-12" of FFC, and through just 12" of FFC.This is okay according to the I2C spec, so long as I arrange the data lines properly and use appropriate size pullups. I have 2K pullups at the microcontroller end, plus I think some weak internal 100K pullups are enabled on the Atmega by the I2C libarary. And through the CAT5 the clock/data lines are each twisted with a ground, and on the FFC it goes: 5V clock GND GND data 5V.QuoteI don't, but they should be... like I said, I followed the I2C spec. But who knows.QuoteI've been told it's bad to put pullup resistors at multiple locations along the bus. I assumed this would affect data integrity in some way. I suppose I could try this as a last resort, but 2K is already really low.

author: Starlord
author_rank: Frequent Contributor
timestamp: May 30, 2016, 01:05:24 pm
content: Quote from: timb on May 30, 2016, 11:01:45 amI am using the Arduino IDE and code base, but with a Atmega1284P. I ditched the Wire library because it just locks if communication with an I2C device is lost. Instead I'm now using this library:http://dsscircuits.com/articles/arduino-i2c-master-libraryThat allows one to specify a time out in milliseconds, and after enabling that my code stopped locking up, but as I described in my previous post, the LED drivers still stop functioning. It used to be they would freeze when the code froze, but now they just turn off. Not sure what's going on there, but I'm going on the assumption that the chip is receiving some command which turns the display off and that if I reinitialize it it will come back, so today I'll be modifying my code to set all the registers up each time I send an LED update instead of just doing it once.I'm certain I'll be able to make it work at this point, though it may not be entirely glitch free. It's about 99% glitch free at the moment, with a single LED driver connected.

author: Fungus
author_rank: Super Contributor
timestamp: May 30, 2016, 06:08:24 pm
content: Quote from: Starlord on May 30, 2016, 12:53:49 pmI say "no".Quote from: Starlord on May 30, 2016, 12:53:49 pmThe only thing that would cause that is if one of the chips somehow misses a clock pulse.(or sees an extra clock pulse because of line noise - same thing, a chip goes out of sync).Quote from: Starlord on May 30, 2016, 12:53:49 pmThe pullups are critical. My money is on the pullups being the problem.Quote from: Starlord on May 30, 2016, 12:53:49 pmWho by? The reference docs don't seem to have a problem with it.eg.http://www.ti.com/lit/an/slva689/slva689.pdfQuote from: Starlord on May 30, 2016, 12:53:49 pmMe? I'd try it as a first resort. Put some 470 Ohm pullups in the middle of the bus and see what happens. If it fixes the problem then you know where to start looking for answers.Quote from: Starlord on May 30, 2016, 12:53:49 pmNot it isn't.2k is far too high for a bus with (eg.) 200pF of capacitance - see the doc I linked above.

author: Starlord
author_rank: Frequent Contributor
timestamp: May 30, 2016, 08:25:17 pm
content: That's not the official spec, but even if it were, if you look at Rp min, the minimum for 5V is a little over 1.5K.The official spec agrees with that:http://www.nxp.com/documents/user_manual/UM10204.pdfAnd has a different spec for Rp min in fast mode plus that the TI datasheet doesn't show.Of course I'm not running in fast mode plus, and I'm not sure all my devices support it. If they did, I could use a smaller pullup. But I designed under the assumption that some devices I attach may not support fast mode plus. Partially because I may eventually want to switch to a SAMD processor and I don't believe they can sink more than 7mA or so on any pin.So assuming not all my devices support fast mode plus, I'm stuck with 1.5K minimum. Now when I designed this I didn't really have a good handle on it, but it now occurs to me I probably should have picked the smallest value I could. But at the time, I thought too low a value would cause problems. Which it will but at long as its within the spec I guess you can't go too low. It's just a matter of higher constant current draw.QuoteJust whoever I asked about this stuff on the forums. I don't remember specifically. It was just a common thing I was told.Anyway, I don't see the spec allowing or disallowing it. But the drawings do show only one set of pullups after each buffer and the microcontroller.Data transmission over long wires is a bit of black magic to me. I know about ringing, but I don't understand it well enough to know when it will be a problem or how to mitigate it. Same for bus capacitance. I'm not sure how much capacitance my cable has, I don't know how to measure it, I don't know how to make an educated guess about it either, though I suppose I'll be googling that in a moment. But I didn't really think I needed to know what it was since I knew the cable length was to spec and I was right near the minimum pullup for that bus speed, so it seems like a safe assumption that I'm below the max pullup.QuoteNot if I'm running in standard mode (100KHz), which I am. In standard mode, according to the TI doc, 6K is the max for 200pF. But like I said I don't know the capacitance of my cable.

author: Starlord
author_rank: Frequent Contributor
timestamp: May 30, 2016, 08:39:04 pm
content: Well according to Wikipedia CAT5E has a capacitance of 52pF per meter, and 7ft of cable is a little over 2 meters, so that comes out to around 110pF. Another site says 15pF per foot which gives roughly the same answer.So according to the TI doc, at this speed, and with around 100pF of capacitance, anything under 10K should be fine for the pullup. So my min and max are 1.5K and 10K. And 2K falls at the lower end of that, so it ought to be fine unless my assumptions about the cable capacitance are wrong.

author: Mechatrommer
author_rank: Super Contributor
timestamp: May 31, 2016, 04:47:47 am
content: the issue maybe comes from the inductance? from your testing, where is your testing? a breadboard?

author: Fungus
author_rank: Super Contributor
timestamp: May 31, 2016, 05:44:30 am
content: Quote from: Starlord on May 30, 2016, 08:25:17 pmOK, butjust as a test, and because you're running an AVR chip which can sink 40mA+ for a short time : Try a lower value resistor and see what happens.If it magically fixes the problem then you know where to start looking for a solution, eg. Maybe multiple sets of 2k resistors placed along the bus might work, maybe you need to slow down the bit rate (there's no lower limit on that, either...)If it doesn't make any difference then you need to rethink your design.Quote from: Starlord on May 30, 2016, 08:25:17 pmYep. Lower is better for the signals, the only limit is "whatever your devices can sink".

author: Starlord
author_rank: Frequent Contributor
timestamp: May 31, 2016, 08:12:41 am
content: Quote from: Mechatrommer on May 31, 2016, 04:47:47 amNope, actual professionally manufactured prototype PCBs.

author: PChi
author_rank: Frequent Contributor
timestamp: May 31, 2016, 02:00:27 pm
content: I'd say that sharing addresses is a bad idea because the slaves can get out of sync with each other. I2C is edge triggered and open drain which makes it sensitive to crosstalk.It's particularly sensitive while the SCL is rising which is inevitably slowly. If one of the salves detects a a few 100 mV wiggle on SCL during the transition it can detect a spurious clock edge and get out of sync with the others.Can you keep the SCL and SDA well away from each other and from other logic signals?

author: Fungus
author_rank: Super Contributor
timestamp: May 31, 2016, 04:57:41 pm
content: Quote from: PChi on May 31, 2016, 02:00:27 pmThis is why you need to fiddle with the values of the pullups and maybe put multiple pullups along the bus. At least put a set of pullups at the end of every long wire.Ten minutes with an oscilloscope would solve this.This document may also be useful:http://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdfYou can detect (and fix!) a stuck bus by sending some clock pulses and watching SDA to see if it goes low. If it does then send a STOP and start again. Any non-stuck chip will ignore all this activity because you never send a START.