ADAU1701 and PIC32 I2C clock stretch issue

carpens Question

Dec 1, 2013 00:00

Hello

I have a circuit with a Microchip PIC32MX250F128D mcu as a I2C master to communicate with a ADAU1701.

I use the standard PIC32 I2C libraries from Microchip.

I want to read signal values using a Readback cell.

I followed indications given in posts like this one:

https://ez.analog.com/docs/DOC-3130

A typical read sequence is:

write 2bytes, read request, read values 3-4bytes.

Everything works fine with SigmaStudio and the USBi interface.

I copied the sequence form the capture window in SigmaStudio to my MCU code and it just doesn't work.

The I2C code is functional because I can read/write to registers in the ADAU1701 (example: mute/unmute commands work fine).

I then probed the I2C bus.

With the USBi the clock is stretched a few us just after writing the 2 bytes and before the read command.

With the PIC32, the clock is not stretched at all and the bytes read are always zero.

I checked everything bit by bit and this is the only difference.

I try to avoid rewriting the I2C libraries or doing software bit-banging but maybe I will have to.

Has anyone came across similar I2C issues with PIC32 and found a solution?

Any suggestion appreciated.

Thanks

Audio Signal Processors

i2c

microcontroller

SigmaDSP Audio Processors

adau1701

Report

ADIApproved Reply

Dec 2, 2013 00:00

Hello carpens,

It sounds like your Write command is working, your Read command is working, and your Data CaptureRead command sequence is not working.

I think the key here is that it takes the DSP core one full audio sample in order to transfer the appropriate data into the appropriate place. Perhaps you are reading too quickly. The "clock stretching" you see in the USBi is probably just a "wait" command, designed to give the ADAU1701 enough time to transfer the appropriate data.

So, I would suggest that you modify your MCU to execute the following command sequence:

Write

Wait at least one audio sample

Read Request

Read

Report

carpens Reply

Dec 8, 2013 00:00

Hello Brett,

Thanks for your suggestions.

I also suspected it was a kind of wait state, and as far as i remember this is the very purpose of the clock stretching procedure.

This is tricky and I have the feeling that the MCU do not detect properly the clock stretch from the ADAU1701 (slave).

I did try using incremental delays between write/read sequences starting with a few usec, but the bytes read were always zero, no matter what was the delay.

Anyway that was a few weeks ago so I will check it again and get back to you on this.

Thanks

Report

bowerymarc Reply

Dec 10, 2013 00:00

take a look at the I2C spec on NXP's website, it does a pretty good job of explaining the states. I2C 'stretched clock' means SCL ls low, is that what you're seeing? When doing a register read you first do an I2C write cycle, followed by a 'repeated start' followed by an I2C read cycle. If you see an extra long high time on SCL between the read and write, look closely at SDA, I'm guessing you're looking at the repeat-start condition, which has it's own timing requirements.

Report

EZAdministrator Reply

Aug 2, 2018 00:00

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

Report