ADAU1467 Eval Board I2C Programming

Question

I'm working with the ADAU1467 Eval board, trying to set it up using a microcontroller through I2C. I've programmed it through Sigma Studio using I2C, and it works; sound starts playing through the speaker's I've connected to the output, and I see data being transferred on the SDATA_IN2 line between the ADAU1467 and the eval board's codec (an AD1937). However, if I send the exact same I2C messages sent by Sigma Studio with my microcontroller, it acknowledges all the received messages but data doesn't start transferring on SDATA_IN2, and sound doesn't start playing. 
 Using a logic sensor, I've confirmed that the register data being sent by my microcontroller is exactly the same as the data being sent by Sigma Studio. The codec is in standalone mode, and hasn't been reprogrammed from the standard code it comes programmed with. I'm using 2.2 Kohm resistors as the pull-ups for the I2C connection between the microcontroller and the ADAU1467. 
 Since the ADAU1467 is acknowledging all the messages, I assume I am actually updating the 1467 registers correctly, but for some reason it isn't beginning to communicate with the codec on the eval board unless it's programmed through Sigma Studio. Does Sigma Studio do anything to facilitate or start communications between the chips on the eval board outside of writing to the registers on setup? I can see it edits the 0xF208 and 0xF210 pins, which control the state of the serial input and output of the ADAU1467, but the microcontroller writes those as well. The only output I see in Sigma Studio is the written registers, and like I said I write to all the same registers in my microcontroller code.

DaveThib · Accepted Answer

Hello LTav, 
 I suggest you step back and start super simple. see if you can talk to each part. I would start with reading a register that has a known value and it is not zeros. See if you can read the correct data. Then try to write to one address and then read back the value and see if it has changed. The PLL settings registers will be good candidates for this because they are usually not zero and they are accessible even with the PLL not active. So see if you can walk with the controller before you try to run with it. 
 After that, I would look at your programming procedure. There needs to be some wait states (delays) in the procedure to allow for things like the PLL to lock etc. You are using I2C so clock speed should not be an issue. Even still, I would wrap a ground wire around the clock and data wires you have flying around. It is great to use ribbon cables and have every other pin be a ground pin so you maintain an impedance for the wires and return current path. Make sure you ground the two boards together as well. I have seen this be an issue in the lab even with I2C. 
 Check that you have pull up resistors installed. The USBi only has very weak pull ups. 
 It certainly is good to use SigmaStudio to control both the DSP and the codec for your initial work. Once you got it running you can easily download the register settings for the codec and then work on getting the DSP to boot up the codec. You are doing well to split up these two tasks to make it simpler. 
 Dave T)

Harishgowtham · Answer

Hello LTav, 
 It seems like you are booting from a controller. I suppose you exported the system files from Sigmastudio. So, the I2C commands that the SS sent when you link compile download should be the same with the exported files (If you haven't changed any registers in the GUI before exporting). If you exported the system files as is from a working project, then I would be fine. 
 So, does your problem lie in entire booting or only with the audio flow? Just setup a project with a DC cell and GPIOs and export the system files and interface with your controller. Then try to read the DC value (or any parameter) or just control the GPIOs from your controller. If it comes out well then, we will conclude that there won't be a problem with communication. 
 Since you mentioned you have a decent I2C signal and correct data transfer, I assume you don't have any problem with I2C addressing and connections. 
 Just to verify, could you please send us a scope shot of your signal and pin connections between the DSP and uC. 
 LTav said: but for some reason it isn't beginning to communicate with the codec on the eval board unless it's programmed through Sigma Studio 
 Sigma studio usually doesn't program the codec unless you manually program it from the master control port. The CODEC will be set to its default rate (48kHz) and default setups after every reset or across power cycle. As long as it is in the standalone mode you don't need to worry about the codec settings. 
 After the booting process is completed from the uC , just probe the serial input and output port clocks (BCLK, LRCLK). These clocks will be going out (since it is set as master by default) once the DSP receives the booting sequence successfully (order of commands which is same as shown in the capture window as well as in the exported system files (default_download_IC_1 function from projectname_IC_1.h file)). If you are seeing the clocks, then we can verify that the codec is getting the serial clocks from the master (serial ports by default). 
 So, I suspect the problem lies in the booting process. Please get back to us with your results. 
 Regards, 
 Harish

Harishgowtham · Answer

Hello LTav, 
 I can see few things here. 
 Firstly, the data and clock pins of I2C is swapped in your diagram. So, Pin 7 must be the clock (SCL) and pin 5 must be the data (SDA). 
 In addition to this, you are providing 5V in the pin 8 (ADDR1). The maximum digital input voltage must be 3.3V. 
 Reg the I2C addressing, Pin 9 (ADDR0) is tied to IOVDD. So, it's a logical 1. You can bring two addresses by changing the ADDR1 (pin8). By grounding (logical 0) pin 8, you will have the address 0x72 or by tying pin 8 to 3.3V (logical 1), you will have the address 0x76. (In both cases, I consider you are writing so I set R/W bit as LOW). Please refer the addressing table in the datasheet. 
 Since you said programming from SS works well, is there a problem with I2C addressing then? So, can you share your entire schematic? 
 I also assume your I2C traces are not too long. Otherwise, you will be getting into signal integrity issue. Are you using jumper cables to connect between devices? 
 Regards, 
 Harish

Partner Forums

Partner Libraries

Products Mentioned

Associated Drivers

ADAU1467 Eval Board I2C Programming