FAQs
English (US) 日本語 | Japanese 中文 | Chinese (Simplified)

Multimaster I2C again.

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multimaster I2C again.

‎06-15-2016 08:00 PM
716 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by JohnR on Tue Feb 08 16:20:17 MST 2011
Hi

I setup two LPC1343 LPCXpresso boards as masters on a single I2C bus. One master reads an ADC over the bus, the other repetively reads data from an EEPROM. The clock rates on the two boards are offset very slightly so that every now and then the master requests coincide.

I had expected that the case statement in the interrupt handler that deals with lost arbritation (0x38) would be triggered when a collision occurred and the system would halt until the error was cleared in software (that I thought I would have had to write).

However, the I2C firmware seems to be smarter than I thought. Looking at the I2C signals on a logic analyser, the transfer that is second to arrive at the I2C module seems simply to be delayed until the first transaction has completed.

Could anyone please confirm that this is the expected behaviour?

Thanks in advance,

John.
0 Kudos
Reply
1 Reply

‎06-15-2016 08:00 PM
697 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by atomicdog on Sun Mar 06 15:13:29 MST 2011
Quote: JohnR
I had expected that the case statement in the interrupt handler that deals with lost arbritation (0x38) would be triggered when a collision occurred and the system would halt until the error was cleared in software (that I thought I would have had to write).

However, the I2C firmware seems to be smarter than I thought. Looking at the I2C signals on a logic analyzer, the transfer that is second to arrive at the I2C module seems simply to be delayed until the first transaction has completed.

Could anyone please confirm that this is the expected behavior?

Thanks in advance,

John.
There was no arbitration or collision since one of the masters took control of the bus first. The I2C module checks the SCL line before trying to control the bus. So the other master saw that the SCL line was low which means another device has control of the bus (or there is a hardware issue). The other master will then wait till the bus is free and then send or receive.

--John
0 Kudos
Reply