Using our I2C adapter inside our Xilinx FPGA XIIC to communicate to the UCD9090A over the PMBus, and using a Salae logic analyser to capture the waveform below, we are reading command 0x8B, the device address is 0x68. Every so often, like 5% of the time the device is not ACKing its address. From this snapshot, it looks like a valid I2C transaction with a NAK instead of an ACK from the UCD9090. Any idea why this would be happening?
I am told by the FPGA engineer that the host the xilinx xiic does support clock streching but I have also asked them to double check with Xilinx. Here this is clearly not a clock streching issue as the clock is not being held low. Sorry about swapping the probes(colors) between the 2 captures
Hi ,
We have a Xilinx XIIC (I2C) device connected to a level translator (1.8V to 3.3V to a 2 * 5 pin connector we use for the TI dongle, which is disconnected, the connector is used for the SDA and SCL clock probes and then straight to the UCD 9090A. I have added 3 screenshots, one that shows a good transaction followed by a failure, and both good and bad transactions zoomed in.
HI
Is this a repeated-start or stop-start?
UCD does not support stop-start for read operation.
Regards
Yihe
Hi Yihe,
The XIIC allows us to move the SDA edge changes in the middle of the low clock, which we have tried with no changes in the result, it didn't fix our problem, for instance, we had it in the middle of the low clock, it still failed once in a while. Please note that the failure (NACK) happens when we write the device address, so there are no repeated start in the failed transaction , it is only one byte with address 0x68, W the UCD doesn't see it and doesn't assert the ACK. the resistors on both signals, SDA and SCL are 2.4K. One difference we noticed is that the dongle has a bit of a delay before it issues the 9th clock for the ACK as shown below, here we used address 0x0B for a device that doesn't exist on the bus to make sure the delay was added by the dongle.
Regards,
JP
Hi Yihe,
We are seeing this problem on each transaction before a failure, so you are %100 right the previous transaction is messing up the state machine, here the stop bit identified with the reddish square the clock should stay high, but it is transitioning for some unknown reason back to 0 at around the same time as the data is going high (reddish square). This is with the XIIC device, we never see this with the dongle. With an I2C clock problem, it is not easy to put the blame on the master or slave device when the clock goes low, but because it never happens with your dongle, I am going to blame the XIIC or its device driver, so we are going to work on this now. Thanks Yihe. If you don't mind let's keep this open, I will keep you posted.
