USB-8451 fails I2C Read after replacing DUT

[John_in_San_Jose]

USB-8451 fails I2C Read after replacing production Device Under Test (DUT)

Using the USB-8451 for I2C communication for production test fixture.  After testing approximately 5 DUTs, the SMBus Read fails.

The USB-8451 talks to the DUTs using I2C “SMBus” commands using I2C SDA (pin 29), I2C SCL (pin 30), and GND (pin 32).  The three lines from the DUT connect to the USB-8451 when the DUT plugs into a connector.

The USB-8451 failure: During an SMBus Read, the USB-8451 buffers the actual read value and sends that value to the computer out on the next SMBus Read.  For the first SMBus Read, it sends a “0” to the computer, even though the actual read data on the I2C data lines is something different. 

The fixture can be “reset” by closing Labview and power cycling the USB-8451.

There is only one way I can get it to work all the time, every time:

Using a “Mux PCA” (National Control Devices P/N UADSR325PROXR) that uses a bank of relays to control the connect/disconnect of the three lines from the UUT to the USB-8451.

Connect: The order is I2C SCL, I2C SDA, Gnd.  125msec apart.  Bouncing of each relay is finished before the next relay closes.

Disconnect: The order is I2C SDA, Gnd, I2C SCL.  100µsec apart.  No bouncing of the relays.

Any idea why this is happening? 

[Thør]

Just to be clear, it seems the problem is that occasionally you'll fall into a series of SMBus Read functions which return the previous value rather than the current value.  When you close LabVIEW and power cycle the 8451, it then goes back to performing SMBus reads as expected.  Did I understand this correctly?

It's possible that the process of plugging the DUT into the connector causes some bouncing on the transmission lines, which might add some data to the buffer.  This data could then feasibly be read in upon the first SMBus Read operation, causing all subsequent reads to lag behind. 

Some questions:

Do you get any LabVIEW error messages when this SMBus Read fails, or is it just bad data?  Additionally, do you have any pull-up resistors, and what are their resistances?

I'm glad that you were able to find a process to get this to work every time, though!

[John_in_San_Jose]

I have a 20k resistor pull up to +5V (on the 8451 module) for both the SDA and SCL lines.

I get bad data only, no errors.  But I do a PEC check for every I2C Read and that fails.

It could just be bouncing connections that cause the problem, but my "fix" has bouncing relays for the connection (not the disconnection).  I also tried to use the NI 9481 for the relays but still had the issue.  Might be a subtle difference between the timing and bouncing of the relays.

I am experimenting with the timing of the connect/disconnect for the 9481, and I will try some solid state relays (to eliminate the bounce).

[Thør]

It's not just the bouncing connections that would cause a problem, but it's the bouncing of multiple lines at the same time.  My theory is that the act of plugging in the DUT is causing some bogus data to be clocked into the 8451's buffer.  For this to happen, you'd have to encounter the uncommon occurrance where the SDA line bounces while the SCL line bounces low.  This may clock in a few bits of data when SDA gets pulled high upon a solid connection.  This may cause all of your data read operations to appear to be "behind" by one, since the buffer already has that initial value.  This may also explain why it happens infrequently, and only upon inserting a new DUT.

I also think that the best fix for this would be to do as you did, and apply the 8451 lines to the DUT one at a time.  This will ensure that they don't bounce simultaneously.  If you find any more evidence verifying what the problem is, it'd be great if you posted it here.  This would be helpful to anyone who encounters this problem in the future.