This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

I2C multi-master arbitration question

Hello


I am considering setting up a multi-master I2C bus with a DM6435 as one of the masters. Now I read about the arbitration process and that made sense until I hit the paragraph in the I2C user's guide where it says (2.9):

If during a serial transfer the arbitration procedure is still in progress when a repeated START condition or a STOP condition is transmitted to SDA, the master-transmitters involved must send the repeated START condition or the STOP condition at the same position in the format frame. Arbitration is not allowed between:
    • A repeated START condition and a data bit
    • A STOP condition and a data bit
    • A repeated START condition and a STOP condition


Now I wonder:

  1. When could this actually happen? I see a chance for this to happen if
    1. one of the masters just came out of reset (in which case I have more problems than that, because that master will likely take over communication, but will have produced a repeated start that it doesn't know about)
    2. both masters sent the same command, but one master wants to terminate the communication with a STOP and the other wants to send a repeated START.
  2. Why does arbitration not take place in this situation? Wouldn't that be the right thing (tm) to do?
  3. If I forgot a case in 1, how is a master supposed to detect that another master transmits a STOP? If master A is pulling SDA down because it wants to transmit a 0 and master B wants to send STOP, then SDA will stay low, the STOP will not be sent, and no device other than master B will ever know that B wanted to send STOP.

Thanks for your help

Markus

  • I think I now see that a conflict between master A sending STOP before master B gets to send a repeated START will result in two transitions (low to high to low) in a single clock high cycle. I'm still puzzled why these situations weren't resolved in the I2C protocol (if you can detect edges (START/STOP), you should be able to also detect both edges, the arbitration would then let START win).

    Anyway, I guess I can work around the issue by avoiding any ambiguous situation where either STOP or (repeated) START could occur.

    Markus