HI, I come across a problem with the use of ADAU1761. when there is a power-on, there is a certain chance that the configuration of the ADAU1761 chip fails.The DSP configures 1761 through SPI interface.In the process of product development, there are also cases that the configuration is failure. To solve this problem, we adopt the method of verification and rewriting. But recently we found that the DSP program has always been in the state of verification and rewriting,so the DSP system can not boot normally. The abnormal rate is about 2%.At this time, the software restart of the DSP still cannot solve this fault, and only the power-off restart can be successful. The SPI communication clock is set to 1Mhz. When the fault occurs , we found through debugging that the SPI interface of the chip could not respond to communication at all. My question is: Under what circumstances will this failure occur? Please reply so that we can locate the problem, thank you.
I do not know of any problems with the design of the SPI port and this part has been released for many years. For troubleshooting, I am asking the question "What would cause the SPI port to not respond?".
Since your system works for 98% of the time then I will assume you are properly formatting the SPI communications so looking internally into the part the most obvious reason is loss of clocks. So what would cause the clocks to stop?
Is the master clock still there and stable?
Is the PLL running?
Did the master clock become intermittent or change duty cycle quickly to cause the PLL to lose lock and latch-up?
On our parts the SPI port will usually get its clocks from the output of the PLL since it is a higher frequency but before the PLL is locked, or if it looses lock, then it will get its clock directly from the MCLK input pin. This is usually much slower rate and so it will not support a faster SPI clock speed. Since we really need to have the SPI port functioning to debug the problem, try to lower the SPI clock speed significantly, 100kHz would be good to try. If you are able to read the registers then then check to see if the PLL is locked.
One other thing to look for is the Core Clock Enable bit. Should that be disabled then you can only read and write to registers R0 and R1. All other registers will fail if the core clock is not enabled. This could also be the reason why the SPI interface might seem like it is not functioning. When testing the SPI read I suggest you read registers R0 and R1. Then you can also see if the core clock enable bit is set in register R0.
Hello Dave.Thank you very much for your answer.
When I looked at the MCLK with the oscilloscope, I found it is normal.
The MCLK frequency is 24.576MHZ.So does the SPI clock still need to be reduced to 100KHZ for testing?
According to your reply, even if the PLL latch fails and the core clock is not enabled. As long as MLCK is normal, the R0 and R1 registers can be read and written normally, but the result of my verification is that the write and read of R0 and R1 are inconsistent. For example, I write R0 with the data 0x0F, but the read data is always 0. I write R1 with non-zero data, the read result is always 0.
Yes, even if the PLL is not locked you can read and write to R0 and R1. The fact that you are getting only zeros is not correct.
Yes, I would still reduce the SPI clock frequency for testing purposes. A 24MHz clock is higher than most master clock frequencies so using 24MHz verses an internal 49MHz I don't think should not cause an issue. With a 1MHz SPI clock there are 24 clock pulses for capturing the SPI transitions and data. Plus there are some internal delays when fetching the data but that is only a few master clock cycles. I am not certain exactly how many in this part but in other parts it is around 8 cycles.
So this means that this is probably not the cause of the problem. It is still good to reduce the speed because there could be other PCB related issues or system related issues that might affect the SPI messages. So we need to continue to investigate and rule out possible causes.
If the part has been powered down it needs to be placed back into SPI mode. It does not seem like this is the issue. I am trying to think of things that would cause the part to not respond to a SPI message. The SPI address is all zeros so it is hard to get that wrong! How do the waveforms look on a scope? Feel free to take a screenshot and post it.
Also, look carefully at the MCLK and power when you power up. Is it always stable during the power up process?
Then the last thing is to check the part closely on the PCB. Are there soldering issues? Your 2% failure is that 2% of all the boards in a production run or is it 2% of the time on one PCB?
2% failure is 2% of the time on one PCB.
I'll check what you said above.