ADAU1761 I2C burst read sequence
Thread Summary
The user is experiencing issues with I2C burst reads on the ADAU1761, where the read data does not match the expected values. The final answer suggests that the issue might have been resolved offline or through a multi-part answer. The accompanying answer provides a debug method using SigmaStudio USBi to verify I2C reads, confirming that the readback command successfully reads the initial downloaded program data. The ADAU1761 datasheet and I2C analyzer captures are referenced to ensure the read sequence is correct.AI Generated Content
Hello,
This is my first experience with ADAU1761. I have uploaded the firmware and registers using I2C burst write SAM D20 and I have a sound at the output, just as it is supposed to. However I would like to be able to confirm that the ram/registers content is as intended after uploading (or during the programming).
Programming start with writing 0x7F to 0x40EB. However if I immediatelly try to read out data written and verify I do not get the same value. So I am thinking:
1. Maybe it is not possible to do so and that I cannot verify all transfers this way?
2. My burst reading sequence is not correct?
My burst read sequence starts with address write 0x70, followed by the two address bytes write, eached followed by the ADAU1761 ack (I can observe also some clock streching).
After this write 0x71 with slave ack is issued and there it goes not as expected.
After 0x71 SDA and ack, SDA remains low for the next 9 clocks. If I check the diagrams in the datasheet I would expect that this 9 clocks period would retrieve 0x7F value not zeroes.
Is there anything I am missing?
3. Is there any other suitable way to confirm that correct content is uploaded?
Thanks!
Audio Signal Processors
processors and dsp
SigmaDSP Audio Processors
adau1761
Processors and Microcontrollers
Hi,
I have moved this question from the Processors and DSP community to the SigmaDSP Processors and SigmaStudio Development Tool community. Please continue your discussion here.
Thanks,
Colin
Hello Ivana,
Sorry for the long delay, this issue was passed along while we were shut down for 2 weeks. Are you still having issues with I2C Burst Reads? You have no issues with downloading the application via I2S writes?
The ADAU1461 datasheet defines the following I2C burst read sequence:
One way to debug this: verify that I2C reads from the ADAU1761 are working using SigmaStudio USBi. I set up a simple test case using the ADAU1761 eval board, and then use SigmaStudio's capture window to copy over the program instruction block from the downloaded program over to the sequencer window.
Here is a screenshot of the burst mode read from the sequencer window. The capture window then shows the Program Data block after the read command is executed. Result: I2C data readback command successfully reads back initial downloaded program data.
I also captured the activity shown above in the capture window using an I2C analyzer. It looks like the ADAU1761 responds to the read command within 3.66 msec before the data read burst. The entire I2C read burst transfer lasts about 28 msec using SigmaStudio.
(zoomed out view)
(close-up view of initial I2C read chip subaddress setup)
(close-up view of I2C burst reads after acknowledge by slave)
Regards,
-JT
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.