i2c multiple master collision

This is a short question but a seemingly important one.

Is it possible for a multi-master i2c bus to have two masters send the start byte at almost exactly the same time?

If so, what would happen?

• Have you tried to look at the specification? It is all there. Commented Nov 5, 2015 at 17:26
• A synopsis can also be found in wikipedia: en.wikipedia.org/wiki/I%C2%B2C#Arbitration_using_SDA Commented Nov 5, 2015 at 17:26
• I am in the process of reading the up on it .... I was reading i2c.info/i2c-bus-specification. I must have somehow missed that section. Commented Nov 5, 2015 at 17:41

It is perfectly possible for two masters to send a start bit at exactly the same time, where with exactly I mean that the difference between the start bits falling fronts is smaller than the smaller measurable difference by the masters.

That's the point: when a master is writing on the i2c bus it is also monitoring it, thus it is possible to determine if a collision is occurring.

Let's say that two masters, A and B, connected to the same bus, want to address two different devices, one with address 0xAE (from A), the other with address 0xA6 (from B). The masters send the start bit at almost the same time, then begin sending the address. Since 0xA = 0b1010 they send the sequence 1010, so far so good, but 0xE = 0b1110, while 0x6 = 0b0110. The fifth bit differs, and A tries to send a 1, while B sends a 0.

Who wins? B of course, because i2c is an open collector bus, lines can only be tied low. To send a 1 you just turn off the output and an external pull up resistor ties the line high, while to send a 0 you turn on a pull down. Master A then is sending a 1, but measuring a 0. Big red flag, bus collision! Master A state machine should properly handle the situation, leaving the bus to B.

Please note that from B point of view nothing has happened, and it continues happily with the frame. That is very good because no time is lost and B can do whatever it needs to do.

While it seems that an open collector bus is the solution to all the problems, unfortunately it is not so. The bus can easily be blocked by any malfunctioning device that decides to hold SCL or SDA low. In such situations it is very difficult to reset the bus, sometimes devices have a reset pin, sometimes you have to power cycle them, sometimes you have to think of something even different. Had to do all the three in different applications.

As a side note be aware that not all masters implement the full spec, some masters do not implement bus collision detection and this can be very bad. In the previous example, if nor A nor B can detect loss of arbitration the address sent on the bus is 0b10100110, i.e. B slave address, but when the ACK comes A thinks it comes from its slave, and after that things can get very bad.

There also is the possibility that A and B wants the same slave. If this happens the ACK is received, and then many things can happen.

Usually i2c devices have many registers that can be written and/or read, the communication frame then looks something like:

slave address; ACK; reg address; data;


(Omitting start and stop bits and WR bit).

The masters start sending the register address. If they want to access a different register it just happens what would happen for the slave address: at a certain point one of them detects the loss of arbitration and gives up.

If the masters want to access the same register, or the i2c device has a default behaviour like "if I detect my address I'll tell you the temperature", then... Everything is perfectly fine! Both masters wanted exactly the same thing, and they are getting it, and this is OK per the standard.

Two communications in only one frame, take that Nyquist!

• What if a and b both want the same slave Commented Nov 5, 2015 at 19:03
• oook, I'll add that. Commented Nov 5, 2015 at 19:04
• @tomcarpenter that sounds like clock stretching not being supported then Commented Nov 5, 2015 at 21:55
• Multi-master often works out nicely, with one master winning and one losing, or with both masters being equally satisfied. There is a danger, however: in some cases it may be important that an operation which is independently requested by two masters be performed twice. For example, if a device includes a command which is supposed to return a unique ID that devices can use for some purpose, two masters that simultaneously send that command and then read the response will end up receiving the same ID. I don't know any way to avoid such a possibility except be either giving masters... Commented May 5, 2016 at 15:51
• ...hard-coded ids, or having them include a reliably-random generator and precede their transmission with enough random bytes that it would be unlikely both would try to send the same thing. Commented May 5, 2016 at 15:51