ADAU1466 ESP32 redaback SPI protocol

Hello khoeds,

It seems you are self-booting from the EEPROM and trying to read the value via uC once the DSP is running. Is that correct?

So, was the self-boot successful? You can identify it by including an audio pass-thru or an LED blink into your program.

Because we must know where the problem is, is it with the self-boot part or MCU reading part.

Also note that, once the DSP is reset or given a power cycle, the slave control port will be back to I2C (I2C is default after power up / hard reset), you have to put it into SPI mode to use SPI from your uC.

Since, you would've hit reset to initiate self-booting, now you will have to put the comms port into SPI, you can insert the below code snippet into your uC code.

Just confirm if the self-boot is successful and DSP is running and try including this toggling code and try again, if it doesn't work then probe the SPI lines and send us the pictures.

Regards,

Harish

Hello Harish

You're wright I'm self booting on my ADAU1466 from the EEPROM and I want to read the value with my ESP32 when all is running.

I actualy don't know if my selfboot is OK. I'm gonna try to generate audio in an output, but I'm newby.

For the second option, it's possible to bring a LED with the program on the DSP ? Have you any exemples or sources I can read to do that?

I try to insert your code but it still doesn't work.

#include <SPI.h>

#define PIN_MOSI 11
#define PIN_MISO 13
#define PIN_SCLK 12
#define PIN_CS 10

void setup() {
Serial.begin(115200);
delay(100);
Serial.println("Démarrage ESP32-S3...");
pinMode(PIN_CS, OUTPUT);
digitalWrite(PIN_CS, HIGH); // Initialiser CS à l'état INACTIF
for (uint8_t i=0; i<3;i++){
digitalWrite(PIN_CS,LOW);
delayMicroseconds(10);
digitalWrite(PIN_CS,HIGH);
delayMicroseconds(10);
}
SPI.begin(PIN_SCLK, PIN_MISO, PIN_MOSI, PIN_CS);
delay(100); // Laisse le temps au DSP de démarrer
Serial.println("Démarrage Connection SPI avec DSP...");
pinMode(PIN_CS, OUTPUT);
digitalWrite(PIN_CS, HIGH);

}

uint32_t readADAU1466(uint16_t address) {
SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE3));
digitalWrite(PIN_CS, LOW);

// 1. Envoie l'octet de commande/R/W (0x01 pour une lecture, Chip Address = 0x00)
SPI.transfer(0x01);

// 2. Envoie l'octet MSB de l'adresse (Byte 1)
SPI.transfer((address >> 8) & 0xFF);

// 3. Envoie l'octet LSB de l'adresse (Byte 2)
SPI.transfer(address & 0xFF);

// 4. Lit les 4 octets du registre de readback (Data Phase)
uint32_t result = 0;

// Utilisation d'un tableau pour les transferts pour une meilleure gestion future (si besoin de DMA)
// Bien que l'itération soit suffisante ici :
for (int i = 0; i < 4; i++) {
// Le décalage vers la gauche s'assure que le premier octet reçu est le MSB de result
result = (result << 8) | SPI.transfer(0x00);
}

digitalWrite(PIN_CS, HIGH);
SPI.endTransaction();

// Note sur le format de données: Le résultat est un nombre à virgule fixe ADAU (généralement 5.23 ou 8.24).
// Vous devrez interpréter ce uint32_t pour obtenir la valeur réelle (par exemple, en décibels [13]).

return result;
}

void loop() {
uint32_t value = readADAU1466(0x004C); // Remplace par l'adresse du registre readback
Serial.println(value);
delay(1000);
}

I'll now work on audio output to know if the selfboot works on my DSP board.

Thanks for your help

Hello Khoeds,

I don't know if your DSP board has any LED provisions since you didn't attach your schematic.

But if you have an oscilloscope with you then you can probe the GPIO pin to know if the self-boot was successful.

Just connect a pulse signal to any of the MP pins available on your board and configure that pin as 'multipurpose' and 'output' in the MP hardware section.

If you included this block in your self-boot program and once you initiated self-boot, you can probe this pin to see if the pin goes between LOW and HIGH. This way you can check if the self-boot is successful.

Please make sure that the self-boot pin is held LOW while writing to the EEPROM by clicking 'write latest compilation thru DSP'.

If possible, please attach the hardware schematic of the board, we may find something in there.

Regards,

Harish

Hello Harish

I've done the tests. When the adau1466 board is connected whith USBi to my computer and sigma studio I see the signal on my scope. I tried to 'write latest compilation thru DSP', all seems to be OK no default warning. After I remove the USBi connector, turn on the switch for sefboot and connect a power supplied 5V. A blue Led flashing but no signal on my scope. Here is the schematic of my adau1466 board :

PDF

So it seems to be a problem of programming EEPROM. There is a few options when I try to 'write latest compilation thru DSP' (I2C, SPI, Mode0, Mode3) and a few more :

I've tried many options, but with the same result.

In my research some people says that the default program on the EEPROM make flashing the LED

The EEPROM on my dev board is a 25AA1024, I've modified the parameters in sigma studio :

And the result is always the same : impossible to write the instructions in the EEPROM for selfbooting

Hello Khoeds,

Looking at your schematics, the pull-up on the SS_M is missing. It's recommended to add a 10K pull up on the SS_M pin between the DSP and EEPROM.

You can see all our Eval boards have that pull up resistor.

Regarding the EEPROM properties window, connect the EEPROM to USBi via SPI in the schematic, the correct EEPROM properties will be automatically fetched, you don't have to change every time.

I also noticed that you set the SPI speed to 20MHz and chip erase command is also wrong.

please change the SPI speed to 10MHz. Please refer the below pic for correct setting.

Regards,

Harish

Hello Harish

I've found a better shematic of my dev board :

PDF

Is the pull up resistor on my dev board ?

In my research I've already found some new document that explain how to program it for sefboot :

The entier document :

PDF

I don't know why but it doesn't work

The programmation of the EEPROM for selfboot works. I've made wrong connections, so the indication above is correct.

I continue my investigation because I can't read the value with my ESP32

I modified my code, specifically the part about the chip adresse and read or write communication. The table no 28 of the datasheet seems to indicate that it's the Bit7 that indicate R/W and I interprated it as the MSB. The paragraph below indicates that it the LSB.

Here is the fonction "readADAU1466()" modified :
uint32_t readADAU1466(uint16_t address) {
SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE3));
digitalWrite(PIN_CS, LOW);

// 1. Envoie l'octet de commande/R/W (0x01 pour une lecture, Chip Address = 0x00)
SPI.transfer(0x01);

// 2. Envoie l'octet MSB de l'adresse (Byte 1)
SPI.transfer(address >> 8);

// 3. Envoie l'octet LSB de l'adresse (Byte 2)
SPI.transfer(address & 0xFF);

// 4. Lit les 4 octets du registre de readback (Data Phase)
uint32_t result = 0;

// Utilisation d'un tableau pour les transferts pour une meilleure gestion future (si besoin de DMA)
// Bien que l'itération soit suffisante ici :
for (int i = 0; i < 4; i++) {
// Le décalage vers la gauche s'assure que le premier octet reçu est le MSB de result
result = (result << 8) | SPI.transfer(0x00);
}

digitalWrite(PIN_CS, HIGH);
SPI.endTransaction();

// Note sur le format de données: Le résultat est un nombre à virgule fixe ADAU (généralement 5.23 ou 8.24).
// Vous devrez interpréter ce uint32_t pour obtenir la valeur réelle (par exemple, en décibels [13]).

return result;
}

I continue my research because I have always 0 as result

Hello Khoeds,

I think you win the award for the post that includes the most detail!! Thanks! However, I am not sure exactly what you are trying to read when you always get 0?

Are you trying to read the EEPROM directly? That is not possible with this processor without hardware modifications to allow you to connect directly to the EEPROM from the USBi.

Also, are you trying to only read two bytes?

One more detail is that after a reset or power cycle, the DSP is in I2C mode. You have to toggle the SS pin three times to put it into SPI mode. That could be part of the problem.

I also noticed that you have a hex value of 5000 in the DC cell that goes to the Readback. If you only read two bytes I think you will only get the zeros and not the "5". So that might also be part of the issue.

Moving over to your comments about the table in the datasheet. This is one of a lot of little errors that are in the Sigma350 datasheets. Due to internal structures, I am not responsible for the ADAU1462,63,66,67 datasheets but, I am responsible for the ADAU1450,51,52 so back in 2018 I made a huge revision to the ADAU1452 datasheet. I suggest you download it and use that datasheet for most of the info. Yes, there are differences but when it comes to the core there is no difference and only smaller changes around the core. Rev-D is the most recent version. You will see in the revision history that I updated the SPI Address details. You are correct that it is the LSB that is the Read/Write bit.

It seems like you are getting close and it is only a matter of one or two little things causing problems.

Dave T

Hello Dave

Thank you for awarding me this prize I hope that it will help some newby like me.

I just try to read the readback value after my RMS table in the adress 0x004C.

As Harish said I include this code to put ADAU1466 in SPI mode :

for (uint8_t i=0; i<3;i++){
digitalWrite(PIN_CS,LOW);
delayMicroseconds(10);
digitalWrite(PIN_CS,HIGH);
delayMicroseconds(10);
}

The readback is a 8.24 value ->32 bits -> 4bytes and I think it's what my code seems to do :

for (int i = 0; i < 4; i++) {
// Le décalage vers la gauche s'assure que le premier octet reçu est le MSB de result
result = (result << 8) | SPI.transfer(0x00);
}

I don't know why it doesn't work

Always for newby if I found the solution, here is my evoluated code for better understanding, I think it's more clear for me.

#include <SPI.h>

//The pins I use
#define PIN_MOSI 11
#define PIN_MISO 13
#define PIN_SCLK 12
#define PIN_CS 10

void setup() {

Serial.begin(115200);
delay(100);
Serial.println("Démarrage ESP32-S3...");

//Define the PIN_CS as an output
pinMode(PIN_CS, OUTPUT);
//To be sure put CS in High level
digitalWrite(PIN_CS, HIGH);
delayMicroseconds(10);

//Placed ADAU1466 into SPI control mode by pulling SS/ADDR0 low three times
for (uint8_t i=0; i<3;i++){
digitalWrite(PIN_CS,LOW);
delayMicroseconds(10);
digitalWrite(PIN_CS,HIGH);
delayMicroseconds(2);
}

SPI.begin(PIN_SCLK, PIN_MISO, PIN_MOSI, PIN_CS);
delay(100);

digitalWrite(PIN_CS, HIGH);
Serial.println("Démarrage Connection SPI avec DSP...");
}

void loop() {
//1MHz to be sure it's not the source of the problem
//MSB first and Spi mode 3 as it says in the datasheet
SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE3));

//Put PIN_CS as LOW for the beginning of the transaction
digitalWrite(PIN_CS, LOW);

//Chip address : 0x00 and read : 1
SPI.transfer(0x01);

// Address MSB : 0x00
SPI.transfer(0x00);

// Addresse LSB : 0x4C
SPI.transfer(0x4C);

// Read and print the 4 byte I'm waiting for
uint8_t Data_Byte[4];

Data_Byte[0] = SPI.transfer(0x00);
Serial.println(Data_Byte[0]);

Data_Byte[1] = SPI.transfer(0x00);
Serial.println(Data_Byte[1]);

Data_Byte[2] = SPI.transfer(0x00);
Serial.println(Data_Byte[2]);

Data_Byte[3] = SPI.transfer(0x00);
Serial.println(Data_Byte[3]);

//Put PIN_CS as HIGH for the ending of the transaction
digitalWrite(PIN_CS, HIGH);

SPI.endTransaction();

delay(1000);
}

Another view to explain what I do :

Any ideas where can be the problem?

I'm always blocked. Has anybody succeeded in retreiving a readback value with a microprocessor like an ESP32 ?

Hello Khoeds,

If you can attach your SigmaStudio project that would be helpful.

The way I like to troubleshoot is to check simple things and basic things first that could cause problems.

The first thing I wanted to check is what is memory location 0x4C being used for? Is it the location of the Readback? You can verify this by using SigmaStudio Capture window and using the USBi. Have the DSP selfboot like you are doing. Load into SigmaStudio the program that you compiled into the EEPROM. Then click on Link/Compile/Connect (not download) then click on the "READ" button the Readback you are trying to read from with the ESP32 and watch the Capture window to see if the address is indeed 0z4C and if you are obtaining a non-zero value. I have two videos on my YouTube channel that describes this. The "Readbacks" video and the "ADAU1452 Capture, Params and Sequencer Windows" video to show you what I am asking. This will just verify you are reading the correct address and that the program is properly loading from the EEPROM.

Once this is verified then we need to move our attention to your program for the ESP32.

I have never programmed an ESP32 and do not know the compiler. However, I have written plenty of PIC microcontroller code and way back in the dark ages some 8052 processors (Yikes). So keep that in mind that I am going to ask you some questions here that is not based of direct knowledge. I was also hoping for someone in the community to chime in. So check the documentation of what I am going to mention.

Based on my experience with C-compilers and SPI utilities, the compiler does a lot for you. I see you are setting up the SPI utility:

SPI.begin(PIN_SCLK, PIN_MISO, PIN_MOSI, PIN_CS);

Then you are writing directly to the CS pin?...

digitalWrite(PIN_CS, HIGH);

This next line of your code also seems to setup the SPI routine:

SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE3));

I would think you would only need to do this once like the pin assignments unless you want to change something of course. Like the clock speed.

But, you have this in a loop... Next in this loop is:

digitalWrite(PIN_CS, LOW);

Ok, yes, setting the CS pin low but I doubt you have to do this directly. I will explain more in a min....

Then you call "SPI.transfer" many times:

//Chip address : 0x00 and read : 1
SPI.transfer(0x01);

// Address MSB : 0x00
SPI.transfer(0x00);

// Addresse LSB : 0x4C
SPI.transfer(0x4C);

Then after that you call it four more times to get the data: (I am only showing one of them here)

Data_Byte[0] = SPI.transfer(0x00);
Serial.println(Data_Byte[0]);

Here are my thoughts on this...

Usually these convenient routines built into the compiler will do a lot for you!

How does it know when it needs to write and when to read? Because it has to write the address to the DSP then read the data in.

you are calling the same function call "SPI.transfer" many times. How does it know what you are doing?

The call, "SPI.BeginTransaction is a curious name....

I am guessing that there is a call that will just do all of this for you. Set the CS output, send the address and then read in four bytes. Open up the compiler documentation on this and see how this needs to be done.

To further verify what I am saying is to connect a four input oscilloscope to the SPI pins and see what you are getting. Is the CS pin going high and low too many times? Is the address 0x4C being properly sent in the correct place and is there data coming back?

Like I said, I have not used this compiler but look at the pins with a scope and see if you are getting what you expect out of the ESP32.

Dave T