ADAU1467 Eval Board I2C Programming

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

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

Hi Harish, thank you for the response and sorry for the delay.

For this project I've switched to using a different codec on a separate eval board. I'm using the ADAU1467 for the audio processing and the ADAU1777 as the codec chip instead of the EVAL1467's AD1937 chip. Here are the control port connections for both the ADAU1467 and the ADAU1777:

I am only using a single I2C bus, so all SDA and SCL pins are connected to one another on a single bus. I've probed the BCLK and the LRCLK pins connected to the ADAU1777; when programmed by Sigma Studio, they begin to give a clock output, but when programmed by the microcontroller they do not. Based on what you said before, this means that the codec is getting the serial clocks when programmed by Sigma Studio but not when programmed by microcontroller.

Both the ADAU1777 and the ADAU1467 receive and acknowledge the register data I send to them from the microcontroller, but don't seem to start communicating with one another.

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

After review, I realized I marked the diagrams backwards; SDA and SCL connections should be switched from what I provided in the diagram. Regardless, I re-checked the schematics to make sure the connections were correct, so they should be fine now.

Thanks for the reminder about the 3.3V to pin 8, I've fixed it.

I've been using address 0x76, which is acknowledged when I pull up pin 8, as per the addressing table from the datasheet.

I don't believe it's an addressing issue, but here's the schematics I'm using. I have two separate schematics I upload separately, first the ADAU1777 then the ADAU1467.

I'm using jumper cables, and I'm almost certain that the problem isn't due to the traces being too long.

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

Hi Dave,

Thanks for your advice, it seems like adding the delays at appropriate times did the trick. I suppose I was sending too many register changes too quickly, or like you said not giving the processes time to lock the PLL. Regardless, I'm getting the output I wanted now.