I2C Multi Master Mode

Indeed there are no examples I know of. And no forum discussion with this topic too. At least not for the last two years.
Multi master mode is rather uncommon.

However, the flowchart in the users guide tells you exactly what happens when. It should give you any information you need to generate your code. Along with the register descriptions etc.

The USCI module supports switching from master to slave operation in multi master mode. So receiving from othe rmaster is not a problem. Transmitting to other masters requires multi-master support (and the ability to be a slave) on their side too, of course.

I also have to use the USCI in multi-master mode and I have some troubles.

In my application I have to avoid disturbing the other master.

So, I need of an reliable mechanism to find out if the bus is free to use it, something like: "the I2C bus is not used right now or from X time ago". First I though the 'Busy' bit is exactly I need, but it is not clearly defined in "MSP430x2xx Family User’s Guide": "The bus busy bit, UCBBUSY, is set after a START and cleared after a STOP." But 'Start' and 'Stop' initiated by my Master, or generally?!? and the description of the register is so unclear:

"UCBBUSY Bit 4 Bus busy

0 Bus inactive

1 Bus busy" 

Indeed, being the inactive master of a multi-master setup isn't really described int he users guide. Adn I cannot answer your question.

The guide covers the situation of two equally-priorized masters. Then the automatic arbitration will solve the problem automatically. You just start adn when anothe rmaster starts a tthe same time, clock stretching will synchronize the two automatically, and the first one that wants to send a '1' but sees still a '0' on data bus will know that there is another one talking and sets arbitration lost flag. And no harm is done, the othe rmaster won't even notice.

For jsu tchecking whether the bus is busy, well, there's one thing you can do: Checking the UCSCLLOW bit. It should be set as soon as the USCI generted SCL signal is 1 and the external lien is 0 isntead. If teh USCI has no ongoing transfer, this bit should go low periodically byt ehhe other masters clock if there is one.
Alternatively you can simply check the SCL port pin. If it is ever low during a period of, say, 500µs, it measn that there is some activity. (assuming an I2C frequency of at least 1kHz for the other master)

Hi Jean-Michel,

Thanks for your cooperation.

Here http://www.i2c-bus.org/MultiMaster/ is written:

"There are I2C environments where multiple masters are driving the bus.

In such case each device needs to be able to cooperate with the fact that another device is currently talking and the bus is therefore busy.

This translates into:

a) Being able to follow arbitration logic. If two devices start to communicate at the same time the one writing more zeros to the bus (or the slower device) wins the arbitration and the other device immediately discontinues any operation on the bus.

b) Bus busy detection. Each device must detect an ongoing bus communication and must not interrupt it. This is achieved by recognizing traffic and waiting for a stop condition to appear before starting to talk on the bus.

If you plan to use a multimaster device on a bus it is essential that all masters are multimasters. A single-master is simply a device, which does not understand the above mechanisms. If a singlemaster and a multimaster are connected, the singlemaster may well interrupt the multimaster causing unpredictable results."

So, the arbitration is not a 'panacea' and I'm not fully agree it you about:

Jens-Michael Gross said:

And no harm is done, the othe rmaster won't even notice.

It will be true if the my master properly handle the situation, but not insist to take the bus. So, it is necessary to have a code under Arbitration Lost. 

Jens-Michael Gross said:

Checking the UCSCLLOW bit. It should be set as soon as the USCI generted SCL signal is 1 and the external lien is 0 isntead. If teh USCI has no ongoing transfer, this bit should go low periodically byt ehhe other masters clock if there is one.

In fact the synchronization more or less is a part of arbitration process:

"The UCSCLLOW bit can be used to observe if another device pulls SCL low while the USCI module

already released SCL due to the following conditions:
• USCI is acting as master and a connected slave drives SCL low.
• USCI is acting as master and another master drives SCL low during arbitration."

and no interrupt exists.

Jens-Michael Gross said:

Alternatively you can simply check the SCL port pin. If it is ever low during a period of, say, 500µs, it measn that there is some activity.

No, such approach is not applicable in my case. I can not afford to stay continuously checking it. 

An I/O port interrupt capabilities on SCL or SDA pin is useful and enough, but unfortunately doesn't exists.

Anyway I hoped someone of TI staff to join to this discussion, maybe we don't know some trick.

tyavashev said:

(or the slower device)

Only if one of the masters does not support clock stretching. Else, the faster device will auto-adjust to the slower devices clock cycle seamlessly.

tyavashev said:

It will be true if the my master properly handle the situation, but not insist to take the bus. So, it is necessary to have a code under Arbitration Lost. 

Yes, of course. If arbitration loss is detected and your code insists of messing with the clock/data lines, this will of course not work.
However, arbitration loss on the USCI will automatically discard all data written to TXBUF (if any) and end the current transaction. So unless you send anotehr start, the USCI won't do anythign on the bus anymore. Of course this may confuse your software if it assumes undisturbed completion of the transfer. But this is the same as with not checking for UCNACKIFG in case the slave doesn't answer.

tyavashev said:

Alternatively you can simply check the SCL port pin. If it is ever low during a period of, say, 500µs, it measn that there is some activity.

No, such approach is not applicable in my case. I can not afford to stay continuously checking it. [/quote]Well, that's your specific requirement and not a general one. :) However, there may be no port interrupt capabilities on the SDA/SCL pins, but you can hook a P1 or P2 pin with edge detect interrupt (or any of the timer module capture intputs) to SCL and get an interrupt on the low-going edge.
Sometimes, not everything canbe solved in software but a simple wire will do the trick.

Jens-Michael Gross said:

Well, that's your specific requirement and not a general one. :) However, there may be no port interrupt capabilities on the SDA/SCL pins, but you can hook a P1 or P2 pin with edge detect interrupt (or any of the timer module capture intputs) to SCL and get an interrupt on the low-going edge.

That exactly I though to do, but I wanted to avoid the hardware changes, due to a lot of devices already produced. :(

tyavashev said:

I wanted to avoid the hardware changes, due to a lot of devices already produced. :(

What about hookup wire? Well, yes, hardware changes are not easily done by a firmware update. But if it is required, it is required.
I had similar cases in the past where new features in a firmware did require a wire connection or a cut on the older PCB versions.
I have also seen 'upgrade kits' that were nothing more than two sockets with a PCB that had a single trace from one socket to the other. Pull two ICs from the mainboard (at times where ICs were socketed DIL part sand no SMD), insert the 'upgrade kit' and re-insert the ICs. So you're not the first one with this problem.

Well, there is a software solution, but you turned it down for performance/power reasons (a valid point).

On some MSPs there is a mapping controller that allows you to map soem module funcitonalities to other port pins. Including the mentioned timer capture inputs. But the G2553 is none of them.

Hi again,

Finally I discover that BUSY flag works perfect. So, if the I2C bus module is properly initialized, the busy flag can be used to watch the bus activities.

In my project I use it to synchronize my activities with the other mister, because I have no guarantee that it(the other master) supports multi-master mode.

But I'm wondering: Why this flag has not an Interrupt?!? It will be a great functionality. 

Unfortunately I still have some problems. For example, I'm not sure the Arbitration Lost works perfect, because I've tried to force it connecting SCL or SDA to GND, but the interrupt causing by arbitration lost happens so seldom, almost never. Of course, my intervention is not synchronized, but anyway I expected to have more interrupt causing by arbitration lost.

tyavashev said:

But I'm wondering: Why this flag has not an Interrupt?!? It will be a great functionality. 

Well, what should be the interrupt? If the bus gets busy or if the bus gets idle? the latte rone is nice to get notified when the own transfer has ended. So it would require two different IFG bits (and IE bits). One more register. Likely, the 'usefulness' of this info wasn't considered so high that it had justified an additional register (or wasn't detected at all during desing Stage).
I'd like to get both events. However, there's always something you'd like to be added to the notification list. :)

tyavashev said:

I'm not sure the Arbitration Lost works perfect

Well, I'm not completely sure when arbitration is checked. When the bus is already busy (a start condition detected), then I think the USCI will not start at all. I'm not sure whether an arbitration lost interrupt is generated. It may be that the USCI just waits with its own transfer until the bus is idle again. But that's just a guess and not explicitely stated in the users guide.