i2c multi master "undefined conditions"

Question

I have read the I2C bus specification and don't quite understand the limitations of a multi master I2C bus mentioned on page 10: https://www.nxp.com/docs/en/user-guide/UM10204.pdf

One the one hand there is the description in the overview that I2C is a true multi master bus. One the other hand, there is the problem that both master have to identify the rare cases of overlapping access. I think i understood the mechanism during the address phase, but the section ends with the following:

There is an undefined condition if the arbitration procedure is still in progress at the moment when one master sends a repeated START or a STOP condition while the other master is still sending data. In other words, the following combinations result in an undefined condition:

• Master 1 sends a repeated START condition and master 2 sends a data bit.
• Master 1 sends a STOP condition and master 2 sends a data bit.
• Master 1 sends a repeated START condition and master 2 sends a STOP

I found a datasheet and interpret it such that these rare conditions are actually an unsolved problem of I2C multi master operation. http://www.ti.com/lit/ds/symlink/ds90uh947-q1.pdf

The I2C specification does not provide for arbitration between masters under certain conditions.The system should make sure the following conditions cannot occur to prevent undefined conditions on the I2C bus:

... above 3 conditions ...

Note that these restrictions mainly apply to accessing the same register offsets within a specific I2C slave

So how to interpret these 'undefined conditions', how do they occur?

Is I2C by design only capable of handling multiple masters if one can guarantee that both will never access the same slave/slave register?

---

EDIT:

I found the following in the Atmega datasheet on page 179

http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7530-Automotive-Microcontrollers-ATmega48-ATmega88-ATmega168_Datasheet.pdf

Arbitration will continue until only one master remains, and this may take many bits. If several masters are trying to address the same slave, arbitration will continue into the data packet. Note that arbitration is not allowed between:

... 3 conditions ...

It is the user software’s responsibility to ensure that these illegal arbitration conditions never occur. This implies that in multi-master systems, all data transfers must use the same composition of SLA+R/W and data packets. In other words: All transmissions must contain the same number of data packets, otherwise the result of the arbitration is undefined.

I'm not sure if they want to say that either

ALL transmissions must be done with the same pattern
or
just consistently per slave.

I guess they mean the latter in that access to a specific slave should be done by all masters with the same pattern of register read/write, repeated start etc. This would be a way to handle it in practice if multiple master MUST access a slave.

If they meant that any transmission to any slave had to follow one specific pattern, some devices would become unusable (16 bit vs 8 bit data transfer).
Or am i missing something here?

Answer 1

Is I2C by design only capable of handling multiple masters if one can guarantee that both will never access the same slave/slave register?

The issue is not limited and there is no fixed solutions (I am afraid) to multiple masters trying to access the same slave. It can be two or more masters trying to talk to each other too.

There are many workarounds (with unwanted software burdens) which are limited to particular project and the person implementing itand use cases and may not work for another requirement directly.

The I2C protocol I use in my current project is a simple three slave one master interface and still it already has 100s of lines of code for many bug fixes and workarounds.

One attempted (but failed) way with two masters was to handover tokens in an orderly fashion. One will start the token and parse it. The guy who receives the token can either return it immediately or can perform operations in this window on other slaves or masters. The system wasn't reliable and all cases couldn't be tested to call it foolproof. It was more like adding new bugs or undefined conditions.

Second use case (one FPGA and other a DSP) was a simple shared Port pins signalling that somebody is busy was helpful. It was never needed in the application to battle for the slave. It was needed just to not crash and fall into undefined state.

I will be really happy to know if someone really has a foolproof suggestion.

Answer 2

They are not saying that any transmission to any slave has to follow a specific pattern. If two masters are addressing two different slaves simultaneously, one master is bound to lose arbitration (as soon as it tries to send a 1, while the other master tries to send a 0--a thing that WILL happen because the two slaves have different addresses).

If the two masters are addressing the same slave, then the corner case of undefined arbitration could occur. It only can occur if the transactions are identical up until the point that one of the three undefined conditions occur.

So, to avoid those three undefined conditions, they recommend that the transaction to a given slave always takes the same format, so both master will be doing that same thing. That way, a repeated start can never get sent from one master while a data bit is being sent by the other master. And likewise the other undefined conditions cannot occur.