ADAU1701 losing PLL Lock

 We have had multiple product failures from the field which are due to the ADAU1701 failing to start or maintain PLL lock.

This results in static noise being outputting on the DAC.


We have faced many issues with the PLL/Clock/Crystal design since conception:

1. Crystal Version

    1. Jan 2018 – PLL lock issues which were resolved by changing layout
      However, 3 years later we again had product failures,
    2. May 2021 – The crystal again failed to start-up which we reported but we received no conclusive response to forum post
      We also experienced the PLL unlocked randomly after the PLL locked at startup.
      To continue production we decided to change to an oscillator instead of a crystal which appeared to fix the issue.

2. Oscillator Version ( Nov 2021). We have again have product failures but it is now losing lock intermittently e,g, 10minutes after power on, but we do NOT see startup issues like the crystal version.  


Examining the fault, it looks highly likely that the ADAU1701’s PLL is going out of lock intermittently.

When measuring the PLL loop filter instead of seeing a constant DC voltage level we see it do periodic steps ~0.5V.

We can also see Pin19, Output BCLK, has large amounts of jitter corresponding to when Pin 46, DAC Out VOUT0 outputting static noise when the product faults.

The ADAU1701 has no way to read the PLL lock status to know for certain this is the fault. Frowning2


We have tried the following to try and determine what is causing the fault:

  • Simplified the design to simple ADC0 -> DAC0 pass through in Sigma Studio
  • Heating or cooling board has no effect on when the PLL loses lock
  • Flexing PCB has no effect on when the PLL loses lock
  • Changing PLL loop filter values (higher and lower) has no effect on correcting PLL loss of lock
  • Check power supplies for noise and tried powering directly from lab supply


Can you please advise what we can do to debug the PLL.


Below is a schematic capture of the current design and PCB layout.

Also included is a capture of the oscillator output at R195.

  • Hello Evan,

    Sorry to hear you are having issues. First of all thanks for writing a great post with all the info I need. Regarding the earlier crystal issue I actually have been working the questions you raised but do not have enough information to post about it at this time. 

    So I looked at your schematic and layout. The layout is done really well after the changes you made back in 2018. So I have no issues. I was not certain in your screenshot which components were the Loop Filter but looking at your old post confirmed it. I circled the components in blue. 

    So the layout looks great and it does look like you have at least a four layer design with power and ground planes correct? 

    The next thing I looked at and would be looking for is an issue with the master clock either being flaky or having poor signal integrity and your screenshot shows that it seems really stable and no large reflections. I do see a small amount of over and undershoot but not enough to cause a problem. 

    You did simplify your project so that is good. I do want to ask if there are clocks coming in from other sources into the serial port. From your description it seems that the 1701 is the master for any serial data transmissions so that would not be a problem at all. 

    So this leaves me with one final observation that I have seen cause this issue. That is the power being too high. In your screenshot of the master clock the clock is a 4V signal not counting the over and undershoot. Your scope show it as 4.08V. This is actually right on the edge of the absolute max of 4.0V. Bring the voltage down to 3.3V and see if you have these issues. We did have a problem with one eval board vendor that stuffed a wrong resistor value into the regulator circuit of the 1701 eval board causing the output to be around 4V. It worked OK when powered by the USB cable but when you used a 5V external source the DSP would put out noise just as you described. So check your power rails to see what they are actually putting out. 

    Dave T

  • Hi Dave, good to speak again, sort of ;)

    • I can confirm that it is a 4 layer design with an unbroken ground plane under the DSP.
    • No other clocks are going into the DSP. see additional test we did below
    • We checked the oscillator input pin 32 using a ground spring clip to minimise the scope ground loop and the results are attached for 22R,47R and 100R in series resistors for R195 on our schematic. None of these changes stopped the DSP losing PLL lock.

    A test we conducted over the weekend,

    We disabled the entire rest of the design, we are configuring the DSP using the eval kit programmer and output the master clock on pin 19. project attached.
    We powered the DSP directly from a DC power supply instead of the onboard DC-DC converter to ensure a clean rail.
    At some point over the weekend the clock has stopped and the PLL has permanently lost lock.

    Repeating the test today, while modifying the oscillator series resistors, the PLL would lose lock after 10-20 seconds.

    The failure is sometimes very repeatable and other times it will take minutes to hours.

    We are really struggling to think of how else to test and debug this bare bones setup.

    We really suspect this is not associated with the input clock/oscillator as the same failure has appeared on both crystal and oscillator designs. But at this point we really have no idea.


  • Dave, thinking ahead if we cannot find any root cause.

    Can we send the faulting unit to Analog Devices for further diagnosis?

  • Hello Evan,

    The voltage levels look better in the recent screenshots. The 100 ohms certainly is best showing much less overshoot and undershoot. So since with that signal you are still having issues, we are probably looking in the wrong place. 

    You have done well to use an external bench supply so we do not have to look there. 

    What is the audio input to the board? What is the level?

    My thinking is that a high level may be causing power supply issues. Just send a fairly low signal that is nowhere near clipping or digital zero. 

    What other signals are on this board? Are you plugging and unplugging signals during this test time? Static shocks can certainly cause resets to happen.

    We may have to take this offline for confidentiality reasons. This may end up being something a bit tricky and seemingly unrelated. 

    Dave T

  • I don't think any of your suggestions apply.

    We are not running any signals into the DSP. The only thing we are doing is powering the DSP, programming it, and then outputting the MCLK. The rest of the system is disabled. No input signals.

    I am very happy to take this offline because we have spend over a hundred hours with this issue over the two revisions of this design and I can't see any obvious faults or design flaws. Escalating this beyond forum posts would be most appreciated.