LPC824 I2C ROM API, bus clock stops

[duaneallen]

I have an LPC824 as the sole master of an I2C bus with two slaves, using the I2C ROM API. It can successfully write to either slave device, but only one of them, a DAC,  can be read reliably. This is implemented on a custom board design of which I have programmed 8 units - only 4 of these can read the sensor device. The units that that fail return an error code of 0x60004 - arbitration lost. After the read is issued to the sensor, it ACKs and the 824 will stop clocking. A logic analyzer reveals that up to that point both the functional and non-functional boards have identical clock and data patterns. Functional boards continue to clock normally, of course. As mentioned above, reading from the other I2C device works normally. Upon encountering the error, forcing bus clocks by switching the pins to GPIO and toggling SCL will cause the slave to output the expected data.

Of particular interest is that by merely connecting an unterminated test lead to SDA will allow normal operation, so I'm inclined to suspect an impedance problem that causes the I2C hardware to become confused (the bus is very short, 2 cm or less). Varying pull ups (I've tried 1.2K, 2.2K and 4.7Ks) and bit rate has no effect.

Attached are screenshots of bus activity on working and non-working boards. I'm running out of rocks to turn over, ideas?

Thanks

[Carlos_Mendoza]

Hi Duane,

Maybe the problem is that the slave device is pulling the SDA line low too fast causing that the SDA is sampled as low when the master drives high during the acknowledge bit of a data receive cycle. I can't get the exact times from your images but a device must internally provide a hold time of at least 300 ns for the SDA signal (with respect to the VIH(min) of the SCL signal) to bridge the undefined region of the falling edge of SCL

Hope it helps!

Best Regards,
Carlos Mendoza
Technical Support Engineer

[duaneallen]

Thank you, Carlos. I think you are correct, as the DAC slave waits 300 ns before ACK and the sensor waits a very, very short time. I imagine the microcontroller may be seeing something which resembles a START on the bus, thus the arbitration error. It became clearer to me after considering the effect of the test lead adding capacitance, which  introduces a propagation delay thus extending SDA for a short while. Ultimately, enabling the glitch filter on the SDA pin allowed the 824 and the sensor IC to communicate. (I arrived at that remedy after finding that enabling Fast Mode plus caused the problem to disappear - using ordinary Fast Mode had no effect. It took a bit of searching to learn that FM+ implements a 50 ns glitch filter. The signals are clean, just need to extend SDA well past the falling edge of SCL...)

Thanks again,

Duane

[Carlos_Mendoza]

Hi Duane,

Thanks for your response an information, it is good to hear that  the glitch filter solved the problem.

Best Regards!
Carlos Mendoza
Technical Support Engineer