Hello, everybody!
I've tested i2c controller in the multi master environment on beagle board xmc (i2c rev4.4 at 100 kHz). Here is behaviors not covered by the TRM. I guess the same issues is seen on omap4.
Issue 1.
In a multimaster environment, after IP software reset, BB-bit value doesn't correspond to the current bus state. It may happen what BB-bit will be 0, while the bus is busy due to another I2C master activity. Here are BB-bit values after reset:
SDA SCL BB NOTES
0 0 0 1, 2
1 0 0 1, 2
0 1 1
1 1 0 3
Later, if IP detect SDA=0 and SCL=1 (ACK) or SDA 1->0 while SCL=1 (START) combinations on the bus, it set BB-bit to 1.
If IP detect SDA 0->1 while SCL=1 (STOP) combination on the bus, it set BB-bit to 0 and BF to 1.
NOTES:
1. Any transfer started when BB=0 and bus is busy wouldn't be completed by IP and results in controller timeout.
2. Any transfer started when BB=0 and SCL=0 results in IP starting to drive SDA and SCL low. In that case IP corrupt the data on the bus.
3. Any transfer started in the middle of another master's transfer results in unpredictable results and data corruption
Issue 2.
BB bit became valid on the next FCLK clock after CON_EN bit set.
So if we try to read BB right after CON_EN bit set it could be 0, and a bit later it became 1.
