Post Go back to editing

PLL losing lock intermittantly

Category: Hardware
Product Number: adau1

PLL losing lock intermittently

I have a mature design with 8 x adau1701 in one PCB piece of insturmentation.   All APs are synced to one common MCLK clock running at 12.288 MHz (I think).  The design has been released for 3 years and we have produced approx 100pc without issue.  Most recently across a batch manufactured we have some APs are breaking out of lock unpredictably.

The condition is very very peculiar in my experience of PLLs.   The VCO in the chip is held (by the PLL loop) to within a few 100Hz of 12.288MHz * divider   (this is about 10-20ppm of locked)  by the PLL but drifts at a frequency every so slightly higher than reference.   If I slightly bias the PLL_FL pin (the VCO line I assume) with a resistor of 100K to 3v3 the device locks.  Biasing it high causes the osc to approach lock from the low F side.       I have tried many many combinations of loop filters and the only thing that seems to have any effect is the resistor.    Many APs will actually lock with no filter caps suggesting that the lock mechanism is normally robust.    Anything from 1M to 47K seems to help a lot.  <10Kohm knocks it out completely as I would expect.      My general experience is that PLLs will lock or jitter but I have never seen on run continuously out of F and phase BUT by such a TINY and fairly consistent amount (+20ppm)

The occurrence is intermittent and in some cases gets better after 10 mins or so running and in others only starts after 10 mins.    I have looked very closely at the loop filter pin and the MCLK signal. The MCLK it is right on 3V pk-pk with risetimes of about 5-10ns.  Looks v clean.   I can measure no difference in impedance between PLL_LP and adjacent components or rails on good and bad devices.   I am pretty frustrated by now and would appreciate any pointers at to root causing this issue.

about 5% of AP devices are affected.   Because my app requires synchronous behaviour between the APs I cannot live with this. 

I note from Ezone that there have been similar issues in the past that sound rather similar but were taken off line. 


Dan Linehan

  • Hello Dan,

    Sorry to hear about your issues. 

    We have sold many millions of these DSPs over a good 15 years or so and there has not been an issue with the recommended PLL loop filter components. You need to use the circuit shown in the datasheet with those values. 

    I would look to see if you are using quality capacitors for the loop filter. NP0/C0G are the best ones to use. PCB layout could also be an issue but since this design has been working for a while earlier I do not suspect that is the issue. 

    Are you using a crystal? I am wondering about the crystal itself. The drive strength of the crystal in this part is on the high side. That said, it sounds like you are distributing the MCLK so you would not have the crystal directly attached onto the part. By the way, most of the other reported issues that were taken offline ended up to be crystal issues usually. 

    The 3V MCLK level is a little low but it is well within the digital levels spec. It would be interesting to see the waveshape. Are there any reflections? Take a screenshot of the MCLKI pin. The shape of the waveform may enter into this problem. 

    Dave T

  • Dave

    Thanks for the fast reply. Will do photo later and will look extra closely at the MCLK signal. Yes, no Crystal. SIgnal is generated by uC and shared by all 8 APs parts. Any comment on the peculiar aspect of non-lock. Does this point you toward any likely mode or mechanism of disturbance. Any further details on how the PLL loop works. Is the freq/phase comparator a freq/quadrature type or simple mixer type. I suspect noise on a supply. Which of the chip supplies is the VCO run from / might I focus on.



  • you can see a video of the lock difference between two APs - one locked and the other not.   The carriers are 10kHz generated from each of the APs so the drift is v v small.   Will send pic of clock signal shortly.   I have to set up for it.

  • I sent you a video of the unlocked plls but it was rejected by your site police as spam or abuse.    If there is a way I can get the link to you let me know.   Meanwhile... here (I hope) are some pics of the MCLK measured at the pin of a locked and not-locking PLL.   clk seen on good partmclk on unlocked PLL

    The slight differences in ringing are largely down to how I hold the probe.    I cant do much better with the scopes available. 

     I managed to upload vid of the phase diff here..   You can see the difference in F.  These are two carriers of 10kHz each generated by the two APs.  The difference in lock is incredibly small.  Perhaps the AP phase detector is catching some additional 'noise' transitions on the MCLK reading its Fre2 as higher that it actually is.    Both clock lines look pretty clean though. 

  • Hello Dan,

    The signal integrity looks to be fine. There is some overshoot but no ringing after the peak that would cause a double trigger. 

    Your video was interesting. How was this generated? You use the word "carrier" which is a curious word from an audio perspective. Are these oscillators running in two DSPs that you are comparing? 

    Which processor are you using? I would like to see the project and it would be good to see the hardware details as well. If you are worried about protecting IP then PM me but just be sure to also request friendship. The default for the forum is to not allow anyone to send you a PM if you are not a friend. People send me a PM and then I cannot reply because of their account settings! 

    At first I thought you were talking about the phase difference because you may see that due to when the sampling is done but when I watched the video I could see it drifting slowly and that is not supposed to be happening. There has to be something simple here we are missing...

    Dave T

  • Its complicated ...The application uses 8 APs to manage 16 instrumentation 'transmit' and 'receive' channels.  Each of the channels can be programmed to generate a 'carrier' using the internal sinwave generator.  This carrier (10 to 20kHz) is used to modulate a light beam.  The beam is detected with a photodiode and then filtered (for the desired carrier), amplified and demodulated using the APs.  Its very much like a radio carrier - thus the term, but with the difference that all the carriers need to be in phase because we are using synchronous detection in the APs for reasons that I wont go into.   AP4 may be used to detect a carrier that was generated by AP1  [Several lights and detectors are used in close proximity to one another thus the need for F diversity]   Processors are ADAU1701.    All 8 APs are synchronised after startup by writing the 2076 regs simultaneously .  I am beginning to think that there is some hard-to-see interference getting into the MCLK line that is adding slightly to the ref Freq.   When an AP is not locked it is always higher in F than it should be.   I am still investigating this theory.  Does it seem a possibility to you? 

  • I have tested a number of units with a 100ohm resistor in series with the MCLK line.  It seems to have fixed the lock problem in each of 5 trials on different boards.  This resistor in combination with the input capacitance of the chip seems to have filtered out whatever was causing the issue.   The slight overshoot is gone and rise and fall times have increased a little.    see photos.   FYI I found that the caps and components assoc with the loop filter (PLL_FT?) pin had minimal influence on lock.  It even locked in many cases with nothing connected to that pin.  A simple cap 1nf to ground or 3v3 worked every time.        

    Please let me know your view on the attached pics/signals

    best regards