ADAU1701 - not getting any inputs (but can see adc hw registers updating on Read All)

Hello woody77,

Are the clocks going to the I2S inputs coming from something that is not synchronous with the master clock that is feeding the ADAU1701? Is the 1701 a master or slave on the serial port?

This part will mute all outputs if there is any clock that does not divide evenly with respect to the clock on the MCLKI pin.

You can remove those clocks and see if it works. Of course, you will not have I2S inputs but the ADC, the DACs and the DSP core should spring back to life.

If that does not work then have a look at the clocks around the part. Look at the Loop Filter pin to see if the PLL seems to be locked.

Check all power and ground and do not make assumptions. Check the ground pins from a known good ground coming in. The same for power.

Dave T

Thanks, when I can get time with the oscilloscope, I'll see what I find probing those.

Is the implication here that the I2C control port is functional when the clock(s) for the DSP core, I2S, and audio ADCs are non-functional? You say it mutes outputs when the clocks don't divide evenly, but what does that look like from within SigmaStudio? (is it visible in the status of the register at 0x081C?)

Hello Woody77,

If the clocks coming into the serial port are not derived from the same master clock, then the DSP will mute. If it is close it will only mute for short periods of time. I have done this in the lab. Setup the part with analog in and analog out through the DSP core. Then I apply clocks from the Audio Precision without using the master clock from the DSP eval board. They are both set to 48kHz but the clocks will not be exact and will drift. As it drifts closer to the correct frequency the audio unmutes and when it drifts away it mutes. It goes from not muting to very short hard to hear mutes to very choppy then full mute. All depends on how close the clocks are to each other. Keep in mind I am NOT listening or using the audio from the serial ports. Just applying clocks. This core is very old and there is no register to tell the core where to get its start pulse from. There must be internal logic that senses clocks coming in, when it does it switches over to it and it also counts the number of master clock cycles verses the LRCLK and if it is not the correct ratio it mutes everything.

We improved this with the Sigma200 and 300 cores by putting a register to select where the start pulse is coming from. I am simply pointing out a weakness. As far as the I2C port goes. I am fairly certain you need a master clock for it to work. I have had the situation on an eval board where the part was not responding because I have the clock source set to external with nothing being fed.

As far as what it looks like in SigmaStudio? This is purely a hardware function and what actual clocks are being applied to the MCLKI and the serial port clock pins. SigmaStudio has no way to know what these clocks are and where they are from and what frequencies. There are no registers that will tell you this.

You have not explained your system and what you are doing with clocks in your system?

If it is coming from Bluetooth, then you will have to switch the MCLKI from the crystal to the MCLK out of the Bluetooth module. This will have to be done externally and with another part like a controller or perhaps some GPIO pin out of the Bluetooth module that signals a connection?

Dave T

> You have not explained your system and what you are doing with clocks in your system?

This is because I didn't do the board design (I'm using a board from Parts-Express / Wondom (KABD-230 is the Parts-Express model), it's a board with the ADAU1701, a Qualcomm bluetooth module (QCC30xx), and a TPA3118 amplifier. This is a hobbyist project, however, if there's an issue with the board design, I want to reach back out to the engineers with feedback to that effect, and see what options I have to minimize issues with this board, as it's about perfect for the 2-way bluetooth speakers that I'm building multiple sets of.

From inspection of the layout, and the presence of a 12.288Mhz crystal + capacitors circuit at pins 31-32 I believe it's using that as the MCLKI source. However, the damping resistor recommended between the crystal and the OSCO pin doesn't seem to be present in this design. But I'm not 100% sure of that. I'll get an analog probe on those pins when I get into the hardware lab, and see what's going on there.

I'll may not know exactly how the various clocks and such are wired up until I can get the board under a microscope and poke at it with an oscilloscope, and that won't happen until I get time to get over to the hardware lab I have access to.