Inquiry on ADAU1761 extern MCLK Clock Synchronization and CRC Verification Method
Thread Summary
The user inquires about ensuring the ADAU1761 is properly initialized when MCLK is sourced from an external chip. The solution involves reading register R39 to confirm MCLK presence and manually calculating CRC via I2C to verify RAM content. The engineer also advises caution when accessing parameter RAM and suggests using internal readbacks for monitoring DSP operation.AI Generated Content
Hello Teams,
In a custom project, the MCLK for the ADAU1761 is sourced from an external chip (referred to as Chip B). Since the main control chip (MCU) cannot determine the exact time when Chip B outputs MCLK normally, I currently use some delays to postpone the initialization of the ADAU. However, I am concerned that if the project undergoes modifications and these delays become insufficient, issues may arise.
Originally, I intended to utilize the CRC function of the ADAU1761, but since all GPIOs are allocated for I2S, it is not feasible to enable the DSP to automatically calculate CRC. Therefore, I would like to inquire whether it is possible for the MCU to actively read the DSP’s RAM content via I2C and manually calculate the CRC for comparison. This way, if any abnormalities are detected, I can reinitialize the ADAU1761.
Is this approach feasible? Are there any alternative or better methods? Thank you!
Best Regards
Keith
Audio Signal Processors
hardware
mclk
crc
SigmaDSP Audio Processors
adau1761
Show More
Hello Keith,
Regarding the MCLK being present. My first thought about this is to take advantage of the fact that you cannot access registers above R0 or R1 if there is no MCLK. So pick a register address that has a default that is not 0x00 and read from that location. If you get 0x00 then there is no MCLK.
For instance, Read from register R39 which has a default value of 0xAA. So if you read 0xAA then you have MCLK.
So first write to R0 and R1 and setup the PLL. Then start reading from R39 and keep reading it until you see 0xAA then you know the MCLK is active.
Wait a short time for the PLL to lock, or check the lock bit, then carry on with programming the part.
You can manually read from the program RAM using the MCU and calculate your own CRC and see if it is good. You need to be careful reading or writing to parameter RAM because if the program is also trying to access the same address the read will fail if the location is busy. I think when you initially program the program RAM and the load in the parameter RAM then read it back and check it then set the DSP run bit and start the program running. Once it is running be careful accessing RAM too often. There is a lot of detail in the datasheet over this.
What most people do is to setup a readback from something internally that changes in the DSP program. Then read that readback periodically. Then if something goes wrong with the program it would most likely show an error. Rather than use a GPIO. Also, instead of writing to a GPIO just write to a Readback and then check it.
There is no perfect way to do this. This is one of our older cores so there are some limitations.
Dave T
Hi Dave
Thank you for the detailed and insightful explanation for this issue. I have verified your suggested approach-specifically, checking for the presence of MCLK by reading register R39 -- and it works perfectly. Additionally, your advice on manually calculating CRC through program RAM reads and the precautions related to parameter RAM access has been incredibly helpful.
Once again, thank you for your time and support.
Best Regards
Keith
Please log in to reply.