This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PCM1864: Occasional clock error(s) with CLKDET_EN set to 0.

Part Number: PCM1864

Hello TI experts,

While working on a maintenance firmware release for one of our more popular products, I decided to look into a bug that is seen only on a very small percentage of the manufactured units. The failing units appear to be working perfectly fine at first (minutes/hours), but then an occasional drop of data/samples can be observed at random intervals (again minutes/hours). The issue does somehow seem to be affected by temperature. 

Our product is using a TDM4 master setup to obtain samples at 30.720 kHz. As we're using a non audio frequency and even sharing a 12.000 MHz 3.3 volts MEMS oscillator between the ADC and the MCU, the first thing we did was to disable the on chip clock detector to gain full control over the PLL and the many dividers. The end result is shown below: 



All sanity checks listed in the datasheet are passed, so I don't expect the setup to be the problem here. 

Digging further into the issue, I discovered that the dropped samples are caused by what appears to be a clock error. At first a few BCLKs are missing, while the PLL is being reconfigured, then zero is output for 8192 BCKs and then finally a fade in is initiated. 

The datasheet states that;



As I read it, clock error detection is disabled, if the clock detector is disabled. As the clock detector is disabled in our setup, I don't see how we can end up getting clock errors anyway?

So that basically leaves me with more questions than answers. I hope you can help me out here.

1. Does our setup make sense or did we miss something?
2. Clock errors? How? Why?
3. If not clock errors, what else could cause that kind of behaviour?

As part of my many experiments, I played around with the PLL constants and well ... fun fact - when setting P to 2 and K to 13.1072 the issue is no longer seen. Unfortunately it fails at least two of the sanity checks, so it's not really a candidate for an actual fix. 

regards

Allan