Microprocessor Control of ADAU1761 via I2C
Thread Summary
The user encountered issues with I2C communication and the 'Program Clear' function when programming two ADAU1761 ICs on a custom board. The delay command is essential for PLL locking and should be implemented in the microprocessor. The 'Program Clear' function is not necessary for a cold boot and can be simplified if the hardware supports contiguous memory writes. The user should ensure the program RAM is filled with zeros if not already done by the file.AI Generated Content
Hello ADI:
The company I work for has been putting together a prototype that uses two ADAU1761 under the control of a microprocessor. Our project requires no run time interaction with the ADAU1761’s so we only need to load the two IC’s on boot.
To start, we verified our overall project viability by incorporating two of the EVAL-ADUA1761’s programmed (one at a time) by Sigma Studio. We then moved on to program two ADAU1761’s on our own circuit board using an onboard uP.
We have based our micro’s I2C instructions on the example project that accompanies “sigmastudio_basic_uc_integration_tutorial” and of course the exported data files from our Sigma Studio Project. We are using a Saleae Logic buss analyzer to detect and record the I2C communications. We have encountered two initial problems that are slowing development:
First, both the Evaluation System Capture Window and the ADI generated “<project name>_ic1.h” file include a Delay function/command. The Delay command “prototype” in SigmaStudioFW.h does not seem to have an explicit address, and no I2C communication ultimately results from the Delay command (in either direction). This is true of both the Evaluation system and of our hardware. In the Evaluation System an I2C buss analyzer shows a delay of about 100mS. Is this delay generated by the external microprocessor? Is the delay essential?
Second, the Evaluation System Capture Window shows a series of five “Program Clear” Instructions each of which clears a separate memory area. The Program Clear Instructions are in the “<project name>_ic1.h” file, but as written, they just try to load the entire Program Memory five times rather than to clear any of it. Is the “Program Clear” function needed on a system that is ONLY addressed at boot right after power on? Or is it essential even at boot?
Also, why is the Program Clear function split up into 5 separate instructions rather than one that clears the entire program memory?
We have other concerns and issues, but we need to solve these first two issues before proceeding.
Thanks in advance for your help!!
Jim Tuomy
Audio Signal Processors
SigmaDSP Audio Processors
adau1761
Hello Jim,
The delay command is essential. It allows time for the PLL to lock. It is something that your controller will need to do. It will need to wait for the specified time. The delay time is a hex number and is in milliseconds. It is included in the output files so your controller knows when it needs to wait before sending the rest of the data.
Regarding your second question. There is always lots of things that SigmaStudio does that I have a hard time explaining why. I am not sure why it is split up into five instructions but I suspect it might be a limitation of the USB interface to I2C we use. If the separate memory areas are not contiguous addresses then you will have to issue a new command to start at a new address. If your hardware is capable of doing it all in one write it should be fine. Now you may have found a bug in that it definitely not try to load in the program five times. SigmaStudio cannot make assumptions of the state of the part so you will often find commands to stop the core and reset etc,. These would not be needed if starting up from cold. You do not even have to clear out the program memory. I do not know of any issues with random data in the program RAM being an issue with this part. You do want to be certain to fill the rest of the program RAM with zeros if the file does not already do that.
I hope you can get further and I will wait for your other questions.
Dave T
Please log in to reply.