MSPM0G1107: Multi-Master issues with I2C/SMBus

The Master is supposed to listen-before-talk, so I always imagined that actual Arbitration Lost conditions were quite rare (very tight race). However, the I2C is susceptible to noise/interference.

I wonder whether the other Master is following the rules. Does it know it's on a Multi-Master bus?

Is the Analyzer trace something you can post?

Hi RT,

Although you have read the bus status, it does have the possiblity two master generate the START signal at next moment.

I think you can check whether the other master support the multi-controller mode. By the way, what the configuration for these two controller, same SCLK frequency?

And when the issue happens, what the command active in the bus, from the M0, or from the battery, or not valid to both?

B.R.

Sal

Thank you for crating this ticket. I think that as the person from whom this topic flowed I can continue :)

Hi Bruce! This is how we check before the start signal if the bus is available using `while (pRegs->MASTER.MSR & I2C_MSR_BUSY_SET)` and you are right: Arbitration Lost happens very rarely, but nevertheless it is sometimes detected by the driver. 

However, sometimes it looks as if the driver doesn't notice that the bus is being used by another master. Logic Analyzer shows that data from the battery (second master) is being transmitted on I2C/SMBus, and the MCU controller seems to think that it is using the bus itself. The result is that we have bad data in the receive buffer.

Hi Sal! 
Perhaps a good clue with this SCLK frequency, because the two clocks of the two mastery differ a little. One about 65kHz, the other about 100kHz, but from what I remember I tried in the configuration to bring these frequencies closer together and the problem still occurred.

It is difficult to say when exactly this problem occurs. The bus in Logic Analyzer seems to behave correctly. We can see the problem from the fact that there are incorrect data in the receive buffer from the FIFO and the driver does not report any error flag. Every time we see this, the other master uses the bus.

Both clock synchronization and arbitration are part of multi-master operation. But both (all) masters have to do them.

I suppose it's possible that the MSPM0 doesn't do them correctly, but at least it claims to [Ref TRM (SLAU846B) Sec 20.2.3.9/.10]. One piece of evidence would be a similar statement from the other master device. (Do you have a part number I can look up?)

Another piece of evidence would be the analyzer trace, which (maybe) will show which master is interfering with the other (i.e. which one talked first).

[Edit: You probably want I2C_MSR_BUSBSY_SET rather than I2C_MSR_BUSY_SET since the former reflects all bus activity and the latter only activity this master has generated. That said: the I2C unit itself is supposed to wait until BUSBSY==0 before starting a new operation [Ref TRM Table 20-56] so checking in software is probably superfluous.]

Hi Piotr,

Piotr Nowwicki said:

However, sometimes it looks as if the driver doesn't notice that the bus is being used by another master.

To clarify this, you can toggle an GPIO with M0 before its read, so that you can see whether it mis-judge the bus status.

B.R.

Sal