Programming the EVAL-ADAU1452MINIZ from MCU via I2C

Also why removing the usb cable stops the DSP program even if the DC jack input is still providing the 6v DC input to the board ?

How can i cancel that ?

Hello fahdovski,

SigmaStudio and the USBi is connected to the reset generator on the eval board. This is so you can reset the part from SigmaStudio if you desire. The problem you are experiencing is because you are unplugging the cable. This removes the power from the USBi so now the reset line that was being held high can no longer be held high and goes low resetting the DSP. So you need to disconnect the USBi from the eval board using the ribbon cable instead of the unplugging the USB cable.

Now if you program the part using SPI from SigmaStudio and want to switch over to I2C control you will not be able to do it. The slave comms port wakes up in I2C mode then is placed in SPI mode by SigmaStudio. Once in SPI mode it cannot be changed back without resetting the part. Then there is the issue of the SPI lines connected to the USBi. The USBi needs to be disconnected. Then you need pull-up resistors. I expect those are on your controller board. Disconnect the controller board when trying to use SPI because those pull up can cause issue with SPI. The two formats are not hardware compatible.

What you could do is use SigmaStudio to program the EEPROM. Then remove the USBi, reset the eval board so it boots up using the EEPROM and then connect the controller board that has I2C pull up on the board. Then you can communicate.

Dave T

Thanks.

Hello,

ADI_REG_TYPE R14_PLL_LOCK_DELAY_IC_1_Default[R14_PLL_LOCK_DELAY_IC_1_SIZE] = {

0x00, 0xFF

}

0x00, 0xFF is the delay value in micro seconds ?

Milliseconds

255 milliseconds. That is huge and is not in sync with the delay that are in the ADAU-1452 datasheet page 32.

Can you elaborate please ?

Yes, it is huge, The person who wrote it into SigmaStudio wanted to make certain it was locked. What I wrote in the datasheet was from the specifications of the PLL lock time. I suggest you poll the lock register and wait until it locks then continue. Then if for some reason it does not lock you can program in a time-out and report an error in your system. If you do not poll the register then wait at least the 10.666 ms I listed in the datasheet. I still would wait a little longer but it depends on how sensitive your application is for bootup time. If you have to shave off every millisecond then wait for 11ms and continue booting.

Dave T