I recently received our new digital audio board which is equipped with an ADAU1467. We have an external master clock signal running at 24.576MHz, 3.9V pk-pk. Verified that we have the master clock on pin 25. PLL_CTRL1 is set to 8.
I use SigmaStudio 4.2 to download a simple program (just input from port 0 and output on ch 0 and 1) to the chip but something is not correct:
Core Control window says that PLL has locked, but N and M values are 0 for CLK GEN 1 and 2. If I change the values and read them back from the DSP I get back only 0.
I can't change CLKOUT, always 0. On the EVAL board it was possible to turn CLKOUT on/off on the pin by restarting PLL_ENABLE.
Moreover, CORE_STATUS is 0.
I have checked all voltages, and RESET is high when the DSP is supposed to be running.
Does anyone have a suggestion for what might be wrong or what I should check?!
I think you are not actually communicating with the part. Are you using SPI? That would be my guess.
If so then look carefully at the SPI connections and look at the data transfers to see if all the signals are correct. At first I thought you were trying to change the CLKOUT pin while the PLL was running but you were able to do it correctly on the eval board. That register is not able to be changed when the PLL is locked and running. It is a hardware lockout.
I suggest you try to read a register that is not a zero after reset. Like the PLL_CTRL0 register. It is an 0x0060 after reset. Do not try to program it so that you do not write over it. Until you can read this register correctly, there is no point moving forward to try to program it.
Check other things about the part.
Make sure the DVDD is correct.
Make sure the reset line is not being held low.
Make sure the PLL is locking. If it is not then the PLL loop filter should be checked.
Also, check the Selfboot pin. Make sure it is not set to selfboot. That would throw a wrench into your efforts.
Have fixed all protocol errors during download, primarily by twisting and decreasing the length of the cables . Still core_status zero. I can change some few register as described earlier, but most of them remain 0. Same thing with PLL_CTRL0 which returns 0x0003 upon restart of the board. I even added write to _CTRL0 at the beginning of the download process and now always have the correct value of this register (0x0060). Still core_status = 0. Downloaded the same program to the EVAL board using i2c. Works as charm. All register values as expected. core_status = 0x0003 (sleep)
The dsp chip is probably damaged.
Here is a zipped file with dsp project and two text files:
Project file. Same (funny... behavior) dsp but running with it's own osc as on the EVAL board. In this way I have been able to program my dsp and the EVAL board dsp with the same code and using i2c (SigmaStudio + USBi). Project does not contain anything else than USBi + the dsp. In this project I do not try to write a correct value to F000, i.e. this is pretty much bare bone init of 1467.
Text file 1. Read result of all control regs F000-FBFF. Reading performed with the sequence tool in SS, i.e. read (FBFF-F000+1)*2 bytes starting at F000.
2. Same read but from EVAL dsp processor programmed with the same project.
I ran a diff on the files and can conclude that the dsp on my board have values in the first 8 regs, everything else is 0! In these first 8 regs, all values are the same (for example PLL_LOCK bit is 1) besides F000 which is 0003, instead of 0060.
Hope that this can shed some light on what is happening with the chip.
Also included chip ID if that is of any interest.
x-ray image of the dsp chip
The chip was probably damaged.
Have received a new board and now the dsp behavas as expected. This is the first prototype and we have some issues on the power part of the board. We have added some patches that we didn't had when we powered up the first board and we believe that it stressed the DSP.
Thanks again for your support,
Are you still having this issue or is this the result of the damaged part you described in your other post?
No. The problem was configuration of register PLL_CLK_SRC which we had configured as XTALIN/MCLK. It seemed correct since we supplied an external clock signal on the corresponding pin (f=24.576MHZ). Now, when we have changed to "PLL CLOCK" and everything works as expected.
Sorry you fell into a trap of a poorly named register. It really should be called the Core_CLK_SRC.
There is no choice of what feeds the PLL, it is always the XTALIN/MCLK pin but you can bypass the PLL and feed the core directly with the MCLK. This happens automatically when the part is powering up and before the PLL has locked, but then this register takes control after the program boots up. So you were running with a core rate of 24MHz which is super slow! Very few MIPS.
Glad you were able to figure it out. Sorry I did not catch this sooner.