Adau1452: Safeload Write with Arduino through SPI
Hi there!
I built an ADAU1452 based proto board, it works great but i'm experiencing problems while trying to send safeload writes through SPI with Arduino. The Arduino is the Nano 3.0 with a CD4050 non-inverting buffer for logic level conversion from 5V to 3.3V.
In more details i've found that certain times the safeload write fails while other times it is succesful. The SPI communication through USBi works great and i'm using same pcb headers both with Arduino to Adau than USBi to Adau.
This is what i'm doing:
- program the dsp through USBi, the program is made from a single Sine Tone block and 1 output.
- write the dsp program to eeprom
- upload the code to Arduino
Dsp program starts with Sine Tone block on
Arduino sketch should turns off the Sine Tone block and then turns it on after 2 seconds, so it's just 2 safeload writes.
With the dsp running the program i often have to hit Nano reset button several times to reload the sketch before get a safeload write success.
The Arduino code is raw and crude beyond belief but it's just for testing purposes to understand how safeload works.
Program sampling is 48Khz and i gave 100us delay between each safeload to stay well large.
I'm working on breadboard and i've checked every single wire:
#include <SPI.h>
void setup(){
pinMode(10, OUTPUT);
digitalWrite(10, HIGH);
digitalWrite(10, LOW);
delayMicroseconds(1);
digitalWrite(10, HIGH);
digitalWrite(10, LOW);
delayMicroseconds(1);
digitalWrite(10, HIGH);
digitalWrite(10, LOW);
delayMicroseconds(1);
digitalWrite(10, HIGH);
SPI.begin();SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE3));
digitalWrite(10, LOW);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x14);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x00);
digitalWrite(10, HIGH);
SPI.endTransaction();
SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE3));
digitalWrite(10, LOW);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x19);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x1B);
digitalWrite(10, HIGH);
SPI.endTransaction();
SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE3));
digitalWrite(10, LOW);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x1A);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x01);
digitalWrite(10, HIGH);
SPI.endTransaction();
delayMicroseconds(100);
delay(2000);
SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE3));
digitalWrite(10, LOW);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x14);
SPI.transfer(0x00);
SPI.transfer(0x50);
SPI.transfer(0xF4);
SPI.transfer(0x4E);
digitalWrite(10, HIGH);
SPI.endTransaction();
SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE3));
digitalWrite(10, LOW);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x19);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x1B);
digitalWrite(10, HIGH);
SPI.endTransaction();
SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE3));
digitalWrite(10, LOW);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x1A);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x00);
SPI.transfer(0x01);
digitalWrite(10, HIGH);SPI.endTransaction();
delayMicroseconds(100);
}
void loop(){}
Hope you can help
Thank you!
Omar
Audio Signal Processors
adau1452
adau1452 spi
arduino
safeload write
SigmaDSP Audio Processors
Show More
hello,
i'm really working on the same topic actually. so i'll just give you a hint about my own experience.
i see you are using the addresses of the PDF (0x14 0x19 0x1A)
did you check that in the compiler_output.log the address of the safeload registers was exactly the one of the datasheet?
in my latest compiles i always get a very different value:
...
0x168 __SafeLoad_Module__ data_SafeLoad [5] =0x00000000,0x00000000,0x00000000,0x00000000,0x00000000
0x16D __SafeLoad_Module__ address_SafeLoad =0x00000000
0x16E __SafeLoad_Module__ num_SafeLoad =0x00000000
very funny! :-) never trust the PDF and check the real thing, if you can.
..really don't know if this can help you.
here the info about my Sigmastudio version:
Hello Omar,
Aventuri is correct that you have to check to see where the compiler placed the safeload registers.
But a couple of things...
First, you do not have to use the safeload for changing a control in the schematic like the Oscillator enable. That change can happen at anytime without causing issues. What the safeload is designed for is changing things like filter coefficients. All the coefficients need to be changed at one time so that the filter does not go unstable. You still can use the feature for changing controls but it is not required.
The second thing is that you may be encountering some signal integrity issues. If you have even a fairly short cable between the Arduino and the PCB that has the 1452 then you can be getting reflections and other transmission line problems. Also, how many layers does your PCB have? Are there power and ground planes?
I did notice that you are running the SPI clock at a fairly high rate, 1MHz. So perhaps try slowing this way down and see if you have more success. This would point to a possible signal integrity issue.
Show us a picture of the interconnect between the two boards.
Thanks,
Dave T
Hello Aventuri,
yes i checked the compile_output.log file but the safeload registers are always the same, probably because it's just a 2 blocks project? I don't know when they are supposed to change though, just guessing.
I'm still with 3.12 version
Thank you for your help!
Omar
Hello Dave,
i checked but the safeload registers are the same. Maybe cause it's just a 2 blocks program? Have no idea when the compiler decide to change but i'm aware of that.
However my problem occurs after compiling, in practice when the registers are not supposed to change.
First, you do not have to use the safeload for changing a control in the schematic like the Oscillator enable. That change can happen at anytime without causing issues. What the safeload is designed for is changing things like filter coefficients. All the coefficients need to be changed at one time so that the filter does not go unstable. You still can use the feature for changing controls but it is not required.
Ok, thank you for enlighten this point. I thought that every audio related parameter would need to be safeloaded. I'll go back to the datasheet and read that part once again.
I hope i'm nut running in signal intigrity issues, by the way the usbi can program the adau1452 fine every time without failing once. However if you have any hints on this it would be very useful to me.
The board is 4 layers with dedicated ground and power planes in between top layer for digital stuff and bottom layer for analog parts. I followed all the pcb design guidelines on both 1452 datasheet than ad1938. In facts the board performs well.
Today i replaced the 4050 with a bidirectional converter and everything worked fine! However i'm not sure it was the 4050, probably it was just a connection issue. However i'm trying the 4050 again and check SPI clocking too.
Thank you for your help!
Omar
Hello Omar,
Can you send a picture of how the two boards are interconnected?
Thanks,
Dave T
Hey Dave,
i used cheap (but short) jumper cable for interconnection between Arduino Nano>bidirectional converter>adau1452.
Actually i don't have a pic to show you cause i have them disconnected. However, before jumper cables, i had a long flat cable which might have been one of the reasons of my high failure transfer ratio.
In the end the issue was fixed and i could succesfully control the parameters of the dsp block with Arduino.
Thank you
Omar P
Hello Omar,
Using a longer cable can cause signal integrity issues. I was going to suggest using a shorter one and also trying to run a ground cable wrapped around, or next to, the clock and data cables. This often helps the transmission problems. I would guess that if you slowed down the transmission frequency it would have worked. That is why I asked you to try it. A cable that is 12" verses 6" can be a dig difference when operating at 1MHZ.
So it is good you are up and running.
Thanks,
Dave T
Please log in to reply.