Urgent: Clock sync problem on production batch
Hi there, how are you?
I developed a product using two ADAU1401s, and each one has its own crystal. We never had any problems whatsoever with the many prototypes using good quality crystals. Unfortunately, the production from China used crystals with higher tolerance, and we get a pretty nasty background noise in many of them.
The problem completely disappears if I force sync between the crystals, or, if I supply both ICs with the clock from the same crystal. I know it is far from adequate, but we really need an immediate solution not to loose the entire batch.
1) Place two wire jumpers, being one between MCLKI and MCLKI, and another between OSCO and OSCO, thus forcing sync.
2) Remove one of the two Xtals, and supply both with the same clock by placing one wire jumper between OSCO of the DSP that has the Xtal and MCLKI of the DSP that doesn't have the Xtal.
Both tested and worked fine, still I would like to know which solution would be "less bad"...
UPDATE: With solution number 2, I still get a healthy 3Vpp clock, so I suppose the oscillator output has decent drive capability.
Please let me know, I really appreciate your input!
Thanks,
Fernando
Solution number 2:
Hello Fernando,
You are right, the solutions are bad and bad.
I think using only one crystal and trying to have it drive the two outputs may be the best of two evils? Does you product need to operate under temperature extremes? Because then the solution may not work under all conditions.
However, I am wondering about your clocking scheme in general. Not knowing anything about your application I am questioning the use of two crystals especially if the parts are talking to each other or other parts in the system.
So when you want to start talking about the next revision then contact me about it.
I assume you have no other master clocks available on the board?
So back to your current situation. If you are only using one crystal then you probably want to remove the 100 ohm resistor from the OSCO pin of the second part. Then jumper the OSCO from the first part to the MCLKI on the second part. This may be the best of all the evils and be the most stable. No guarantees. My thinking is to not connect together two different oscillator buffer outputs. It is not recommended to use this output to drive an external part but you don't have many choices. The good thing is that the parts are very close together.
Good luck! Let me know how it goes.
Dave T
Hi Dave,
Thank you very much for your reply. We just upgraded 100 units, while still maintaining the 100 ohms resistor. The oscillator works just fine and the output is 3.3 Vpp, very strong.
I only have this clock, although I do have a PIC running with a different clock but that's on a different ground plane, so no interactions whatsoever. Actually, the PIC communicates with the DSPs using SPI via ADUM1401, so that was properly done
With the prototypes, having the two DSPs running with separate Xtals was perfectly fine. However, on production the mismatch between Xtals reduced the SNR. I understand that I should have one DSP providing the MCLK via MP11 pin, but that was already used. Next time for SURE I will have a master clock. Actually, next time I may use ADAU1442 or a SHARC 21489. The only thing that makes me scratch my head about using the SHARC is the CCES that is not free. I can code most of the algorithms I need, however, Sigma Studio makes life so much easier...
Btw, could you kindly send me a PM with your email? I will start developing a new DSP soon, and your contact info may come in handy.
Thank you very much for your help!
Please log in to reply.