ADAU1772 is not working correctly after assembly programming.
Hello,
I am loading ADAU1772 program in assembly following this tutorial: Booting a SigmaDSP from a microcontroller with no C compiler .
In SigmaStudio I got project which is supposed to redirect input ( which is sound from laptop's headphones socket) directly to output, where I have connected my headphones. I just want to pass sound throughout ADAU1772 without even modyfing it. The problem is that after programming all I can hear is noise (hum). I used Saleae Logic Analyzer to follow I2C communication while programming and transmission looks exatcly the same as it is said in TxBuffer_IC_1.dat and NumBytes_IC_1.dat files. I got no idea what can be wrong, is there anything else I have to care about when I program in assembly ? Maybe I have to write some data to some extra regiters or I have to prepare ADAU1772 to programming process? I checked programming transmission byte by byte and everything looks perfect.
I rather reject that SigmaStudio project is incorrect cause I got it from a person who used Evaluation Board to program ADAU1772 and everyting was right.
adau1772
Integrated/Special Purpose A/D Converters
assembly
Audio CODECs
Hello,
From your description it appears that your code runs fine when downloaded via SigmaStudio, but not when booting via your uC. I've had similar problems when my uC didn't wait long enough for the DSP to "wake up" before stuffing it with code. More specifically, be sure you're following everything on Page 30 of the data sheet, including polling the PLL lock bit if used. Generally, any deviation from the needed wait times cause the DSP to load incompletely. The usual symptom is no sound, and/or the noise you're experiencing.
Best regards,
Bob
I do not use PLL and I wait much more than 12 ms that is needed for internal reset. Do you remember what exactly was the cause in your situation ? Did not you wait enough time after internal reset ?
Hi,
We were booting a -1701 and not waiting long enough between reset and loading of code via I2C. Since you report that your uC is waiting enough time for your -1772, evidently your issue has a different cause. One other possibility I can suggest: we also had to insert short delays (a few microseconds) after each I2C Stop command before the following I2C Start. Previously we had not needed these until our most recent project, when we switched to a faster uC. Since you're coding your uC in assembly language, likely it's running quite fast-- thus adding similar delays may help.
Perhaps others who have experienced troubleshooting SigmaDSP booting, especially with the -1772, could jump in and offer more specific help.
Bob
After each stop command I am handling UART so there is about 12ms delay between each packet. Maybe it is too long ?
What is more, if something is wrong with timing then why I get ACK properly after each byte, I do not understand.
I have discovered one more weird behaviour. In datasheet it is said that when I issue invalid subaddress there will be no ACK on I2C. I change subaddresses to wrong values but I still get ACK after each byte.
This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.
Thank you,
EZ Admin
Please log in to reply.