Original question:
Yellow SCL
Blue SDA
About the situation
Only the slave (ADS 1119 address is 0 × 49) and the master-side bus buffer (P 82 B 96 TD) are connected to the bus.
The following operations were performed when performing READDATA.
As indicated by the waveform of the oscilloscope, the slave IC returns ACK at 8CLK.
Question
・Why does the slave IC (ADS 1119) return ACK at 8CLK?
・Is there a solution?
Thank you and best regards,
Hi Kazuya,
The ADS1119 and the ADS112C04 share the same digital interface. The ADS1119 does follow the I2C communications protocol and supports Standard, Fast, and Fast+ modes. The I2C timing requirements are given in the datasheet in section 6.6. The testing uses bus capacitance between 10pF and 400pF. The pullup resistor is 1k. Using wire connections will add bus capacitance. Changing the pullup to 1k may also improve the communication.
If we go back and look at the original scope shots you provided of the communication, We see a:
And here is when it appears the peripheral is not fully completing the communication. Normally the ACK would begin on the falling edge of the 8th SCL and hold low through the 9th clock. Note that at the point of discrepancy that the transition appears to take place on the rising edge of the 8th SCL and not the falling edge. This is where I suspect a glitch is taking place that is small enough to not show on the scope plot but also long enough to register as a clock pulse at the ADS1119.
If there is a communication error, there should be an error handling routine in the firmware. You cannot assume that the communication will always work as expected. In the scope shot, it appears that the communication never actually completes. Maybe it does and just not shown. But I have seen may cases where there is no error handling routine for communication or bus error with I2C where the bus will hang requiring a reset.
Another thing to try is to issue a Repeated Start instead of a Stop and Start between the write and the read.
Best regards,
Bob B
Hi Bob
The cause of the error is that a 1 MHz glitch occurred before the 8 clock of SCL, so it returns NACK at the rising edge?
Why does it return NACK at the rising edge??
Errors occur only once or twice a day.
Best regards
Hi Kazuya,
I believe that your drawing is a mostly accurate representation of what is going on except in the error state the 8th clock falling edge will return SDA back high and the micro will see a NACK at the 9th clock. In the normal case, SDA returns high on the falling edge of the 9th SCL which signals an ACK. The ADS1119 is seeing the glitch as a clock. The datasheet is showing for fast+ the following information:
If there is a slight ring on the clock edge or a transient that goes low for 500ns, the ADS1119 will see this as a valid clock. Consider that noise can be picked up on the wiring or there could be some form of ground bounce that may also be a factor. If you are making the connection to the ADS1119 via wires, how is the DVDD and GND connected between the micro and the ADS1119?
A logic low for SCL is 0.3*DVDD. If the DVDD for the ADS1119 is 5V, then a logic low is 1.5V or less. The glitch to be considered a logic low only needs to go to 1.5V on SCL.
Let's consider that this glitch is taking place, and all possible improvements have been made. The question still remains in how is the firmware handling a NACK? You cannot have perfect communications for all time. Events can happen where you would receive a NACK.
Something like the following should be implemented in your code:
Best regards,
Bob B
