ADAU1761 single write/read question
Thread Summary
The user encountered discrepancies in the I2C timing diagrams for the ADAU1761 chip, specifically between Figure 49 and Figure 51. The correct sequence includes an ACK from the slave followed by a stop condition, as confirmed by the ADAU1452 datasheet. The issue might also involve the master NACKing the last byte read to prevent communication hang. Analog Devices will correct the datasheet.AI Generated Content
On of my custimers is having difficulty doing a single write and read using the i2c bus on a ADAU1761 chip.
If you look at page 39 of http://www.analog.com/static/imported-files/data_sheets/ADAU1761.pdf, you will see that the figure 49 and 51 don't match.
On figure 49, the transaction finishes with a Ack Slave and Stop.
On figure 51, the transaction doesn't finish with an Ack Slave, just a Stop.
Which one is right?
Audio Signal Processors
SigmaDSP Audio Processors
adau1761
Hi VicZ,
The ADAU1761's datasheet appears to have a slight error in the first I2C timing diagram. The end of Figure 49 is missing half of a clock cycle! I checked the datasheet of a newer SigmaDSP, the ADAU1452, and this figure inaccuracy appears to have been corrected there.
I have copied the figures here for your reference. In the three figures, you can see a single write, a burst write, and a burst read. In all cases, there is an ACK followed by a stop condition, as in the I2C protocol definition.
(Click the images to increase their size on your screen)
By the way, if you could post some screenshots of your customer's signals here, that would help us to debug the issue.
Thanks for the heads up about the ADAU1761 datasheet, Yagami. We will get that fixed!
Regards,
Coleman
I just realized that it might be a little bit difficult for some people to see exactly what the issue is. So, here's a zoomed-in detail of the discrepancy.
In the case of the ADAU1761 datasheet's Figure 49, the data changes on the falling edge of SCL, the ACK is registered on the next rising edge, and the data line goes high (prematurely) on the next falling edge of SCL. This does not meet the requirements for a stop condition, which is described in this picture that I grabbed from the Embedded Systems Academy website:
Note that the ADAU1452 datasheet shows the stop condition correctly; SCL goes high first, and then SDA goes high after it.
So, the ADAU1761 diagram can be fixed simply by adding half of an SCL clock cycle!
Hi All
I had a problem reading from the ADAU1761. When you read a sequence of bytes from the device, the master needs to ACK all read bytes apart from the last one which it NACKs and then sends a stop bit. If you ACK the last byte read, you stop all communication.
Might be the problem you are seeing (took me a while to get to the bottom of it).
Regards
John
This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.
Thank you,
EZ Admin
Please log in to reply.