We are facing a problem with ADAU1361 audio codec. Sometimes, during the programmation of some registers, the register value is not correctly token in account by the ADAU.
To force the problem, we've written a 'torture test' of the ADAU. Our ADAU driver do the initializing sequence and power down sequence continuously (with some delays between these sequences). These sequences are the same that we use in the normal software, but done more frequently. Some register content check was added during the debug process to identify the source of the problem (at first, we were only observing the bug because of the BCLK signal not present).
We've oberved that when the problem happens, the PLL is unlocked (reading the R1 register , the lock bit is reset to 0).
Before programming the ADAU, our driver enable the PLL following the datasheet procedure (we poll the R1 lock bit to check when the PLL is locked).
I've also observed the input clock of the ADAU (26MHz in our case) and I didn't saw problem in it (no 'skipped' pulse, or delays).
What can cause the ADAU PLL to unlock ?
You may be causing a different problem by doing this torture test since I am not sure if the PLL not locking is your original issue? When you said "the register value is not correctly taken into account?" are you reading the register back and it is not the correct value?
Are you using SPI or I2C?
If I2C then what are the values of your pull-up resistors and how many devices are on the bus?
For the PLL questions:
What are the delays?
How long to you wait once the power is up and stable and the master clock is present on the pin?
How long do you hold the power down before bringing it back up?
This is important, can you show me how you are powering down the part?
Are there other pins that have voltages on them when the part is powered down?
First, I apologie for the late reply, I probably missed the forum notification.
Indeed, when the problem arrise, the register read back is not at the value it should be. We are using SPI. The frequency is next to 10MHz (but I tried with slower speed down to 5MHz and still had the problem).
- What do you mean by delays ?
- The part is not powered-down physically (I mean that the power is not removed). It is simply powered-down in the software manner by stopping the PLL, putting some register like R3 / R35 with extreme power saving, disabling channels ,...)
- The master clock is always on and therefore is already stable when the 'power-up' sequence (as for power-down, it's simply powered-up by setting registers values) is done.
- The time between the last register write in 'power-down' sequence and the next 'power-up' sequence is at least 18ms.
- Do you need the complete power-down register sequence ?
The delays question was from your post:
To force the problem, we've written a 'torture test' of the ADAU. Our ADAU driver do the initializing sequence and power down sequence continuously (with some delays between these sequences).
I would also like to know if you have delays when initializing the PLL.
I would like to see your sequence.
The delay between a 'power-down' sequence (software power-down, power stays on) and a 'power-up' sequence is around 18ms.
The master clock is also always enabled and stable (output from a txco). There is no special delay when initializing the PLL, we simply write the registers (write R0 to ensure that the clock source is MCLK, write R1 with the proper settings for our requirements first without enabling the PLL, then write R1 with PLL enable bit set (as per datasheet recommandation), sleep for 1ms to ensure that the lock bit is reset, then read back the R1 register until the lock bit is set. Once the lock bit is set, the R0 register is written with the correct settings (select clock source PLL, set clock rate and core clock enable). Then, R3 and R35 are written to put the device in power saving modes until the ADAU configuration is requested by upper layers.
I can send you the full sequence in private mail if this is needed. Also, I've got the full SPI messages sequences 'readed' on the SPI bus using a logic analyzer (the aim was to ensure that no corruption or errors were present on the SPI bus). To view it, you need to install the DSView software from DSLogic (I might be able to output the full dump in a PDF file but this would loose all timings informations that we can get with the DSView software.
So when you power down you first shut down the PLL? Then write to R3 and R35? I assume you switch over from the PLL to MCLK Pin for the internal core clock then shut off the PLL Enable bit? Then you would be able to write to registers R3 and R35 because there is an internal clock at that point. But it will be slower.
It seems to me that 18mS is too short of a time to wait between cycles but I cannot give you a good reason why. This is just my gut feeling on this. Try to increase it to around 1 second between power ups and see if you still see the failures in locking. Unfortunately the datasheet does not say anything about the average PLL lock times.