I2C Multimaster Arbitration does not work

Hi,I have connected two NS9750 using the Processor internal I2C. When one of them looses Arbitration it generates a M_NO_ACK_IRQ (2) instead of a M_ARBIT_LOST_IRQ (1). This causes the driver to generate a stop condition. But on arbitration loss it should decouple from the bus. Does anyone have the same problem and is there any way to use the NS9750 in a I2C-multimaster environment ? Jochen

Hi,Investigations showed that the NS9750 can not keep the I2C-Timing spec correctly. The I2C spec says that after a Stop condition the bus must be idle for 1.3uS in fast mode and for 4.7uS in Standard mode (called t_buf in I2C spec). Here is what happens in the NS9750: When the bus is used by an other master the NS9750 waits for a stop condition and then generates a start condition with No Delay ! This happens when SDA raises above 1.8 Volts. So the Signal never reaches the 0.7*Vcc=2.2 Volt which is required by the I2C-Spec. The devices do not detect the start condition. The previous device is still active and will not acknowledge the address. This causes a not acknowledged interrupt. Is there any workaround for this ? I need Multimaster I2C urgently ! The image from Oscilloscope shows the bad stop/start condition in the middle of the image. Jochen

Hi,When I make the I2C Bus waiting for bus free it will generate a start condition with no delay (as shown in my previous posting). But there is an additional bug ! A following repeated start condition will be delayed by exactly 6.55360 ms from the faulty start condition. No matter what speed (clref) i’m using. I made a test measurement: make sda low manually (start condition) tell the NS9750 to do an I2C-transaction release sda manually (stop condition) The results you can see in the following measurements from oscilloscope: print_10.tif shows an overview of the transaction. print_11.tif shows the buggy start condition. print_9.tif shows the repeated start condition with the exact delay measured from the faulty start condition. Jochen

Programming the spike filter width to 640ns increases the T_BUF to at least 640ns which is enough for all chips i found (The standard says 1.3 uS). Such a high spike filter width is only possible when the prescaler is enabled (VSCD Bit). When VSCD is set a spike filter width of 1 means about 32 CPU-Cycles (160ns at 200MHz) (estimated). This does not allow to use the I2C at 400kHz. I use it at 170 kHz. Combinations with non NS9750 masters can cause trouble. Jochen