ΣSigmaStudio Ask AI Русский Log in

ADAU1761 boot from uC

SigmaDSP & SigmaStudio ltwilkerson Apr 19, 2016 00:00 1 replies Original on forum ↗
Subscribe
ltwilkerson Question
Apr 19, 2016 00:00

Good morning!

I've been attempting to boot a ADAU1761 dev kit using a Cypress PSoC5LP dev kit, but have had no luck.

I'm following Wilfrido Sierra's tutorial, <How do I create the microcontroller code to interface to my SigmaDSP? > but I think SigmaStudio is generating the wrong register values as the global variables defined in the export files do not match up with the registers outlined in the data sheet; see attached image.

I can write and read the ADAU1761 registers. I read the first and last regs written in the "default_download_IC_1()" function to ensure the device has been loaded.

Any help would be greatly appreciated and please let me know if I can provide any additional information!

Thanks!

-Ryan

Audio Signal Processors

SigmaDSP Audio Processors

adau1761

DaveThib Reply
Apr 20, 2016 00:00

Hello Ryan,

Sorry for the confusion. The R0,R1,...Rx numbers you see on the left of your screenshot are generated to just provide a reference for the "C" software for the individual register writes. So is only the order that the registers are written not the register numbers. Unfortunately, the register names on this part are also R0, R1,... etc. So I see your confusion.

So if you look at the xxx_IC_1.h text file, you will see the defiles for these register values. (Note, the "xxx" is your project name) Here is an example:

/* Register Default - IC 1.Sample Rate Setting */

ADI_REG_TYPE R0_SAMPLE_RATE_SETTING_IC_1_Default[REG_SAMPLE_RATE_SETTING_IC_1_BYTE] = {

0x7F

};

So here you see this is the first register that will be written to so it is given the name "R0" and in this line it is picking up the number of bytes for this register and setting the default value.

If you look into the file "xxx_IC_REG.h" you will see the define for the actual register information:

/* Sample Rate Setting - Registers (IC 1) */

#define REG_SAMPLE_RATE_SETTING_IC_1_ADDR 0x40EB

#define REG_SAMPLE_RATE_SETTING_IC_1_BYTE 1

#define REG_SAMPLE_RATE_SETTING_IC_1_VALUE 0x1

Here you see the register address in hex and the byte variable that was used above.

Then go back to the xxx_IC_1.h file and look further down you will see where all this information is collected together and output as a data stream for I2C or SPI.

Here is how it starts:

/*
* Default Download
*/
#define DEFAULT_DOWNLOAD_SIZE_IC_1 40

void default_download_IC_1() {
SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, REG_SAMPLE_RATE_SETTING_IC_1_ADDR, REG_SAMPLE_RATE_SETTING_IC_1_BYTE, R0_SAMPLE_RATE_SETTING_IC_1_Default );
SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, REG_DSP_RUN_REGISTER_IC_1_ADDR, REG_DSP_RUN_REGISTER_IC_1_BYTE, R1_DSP_RUN_REGISTER_IC_1_Default );
SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, REG_CLKCTRLREGISTER_IC_1_ADDR, REG_CLKCTRLREGISTER_IC_1_BYTE,

This command assembles the device (chip) address, then the register address from the earlier define, then it sends the number of data bytes to send and then finally, the data with the "R0" in the name.

So the very first register write is R0, Then R1, etc. The actual register is a very different number. This number is generated to give an order to the register writes. It is common for a startup routine to access the same registers at different time. For instance, to mute the outputs first, then all the clock setup is done along with other settings that might cause a click or pop, then when it is all done it will again write to the register to un-mute the outputs. This is later in the sequence and needs to have its own name to distinguish between the two different writes.

I hope this helps...

Thanks,

Dave T