ADAU1452 Flash eeprom with microcontroller
Hello,
In order to update my products, I need to flash the DSP's eeprom for selfboot with a microcontroller.
For ram footprint reasons, I can't send the spi data at once (i.e. I can't send all the bytes for the Program @0xC000, the DM0 @ 0x0000 and the DM1 @ 0x6000).
Can I split those data into multiple SPI commands, such as :
send 256 bytes @ 0xC000, then 256 bytes @ 0xC100 etc...
I would do the same for all 3 "banks".
Thanks for your help !
Audio Signal Processors
adau1452
spi
eeprom
microcontroller
sigmastudio
SigmaDSP Audio Processors
Show More
Yes, The DSP memory is word addressable, so this should not be a problem as long as everything is written before booting.
Ken
Hello Ken,
Thanks for the very quick answer. I have an additional question though :
Is there a way to force sigma to send its data with the same pattern ? I would like to send the program data 256 bytes at a time as well, is that possible ?
Thanks !
Clement
Hi Ken,
It seems that sigma sends its data 1023 bytes at a time (i.e. it separates data into packages and for DM0 for example, it sends the data at 0x0000, then the data at 0x03FF, then the data at 0x07FE etc).
Is there a way to reduce the package size to 256 bytes so i can compare easily what sigma sends with what my microcontroller sends ?
Thanks for your help,
Clement
Hello Clement,
It looks to me that you are wanting to write to the EEPROM from your micro and not to the DSP memory. The EEPROM can be addressed a byte at a time if you like but the problem is that the EEPROM is sitting on the master control port and your micro is sitting on the slave control port. So you will not have direct access to the EEPROM unless you make some sort of hardware provisions for doing that. That can get a little tricky.
So to program the EEPROM you will have to go through the DSP to do it.
You will have to do it in a similar way to what SigmaStudio does. What it does is loads in a program that is a kind of data transfer server. You send it data and tell it where to put it on the EEPROM and it will write it to the EEPROM. There was a post that discussed this in detail on the forum, I will look for it...
Here is an older one...
https://ez.analog.com/dsp/sigmadsp/f/q-a/65079/write-eeprom-through-adau1452/148921#148921
This one is a good post with lots of detail.
https://ez.analog.com/dsp/sigmadsp/f/q-a/118062/adau1452-selfboot-eeprom-commands
Let us know if you have further questions.
Dave T
Hello Dave,
Thanks for the links, I actually based my developpement on these.
I am not trying to access the eeprom directly, I want to download the selfboot data through the DSP. Exactly as sigma does but I can't get it to work properly...
What I do is :
- I compile my project
- I clear the capture windows with the "X"
- I "Write lastest compilation through DSP
- I set my eeprom settings
- Then I export the data like this (I select the entire output of the capture window, including the RAM code for the "eeprom downloader" and all the pages writes etc.)
It seems that my microcontroller sends the same data as Sigma (I analyzed the SPI data coming from the sigma "flasher" and compared it with what my µC sends, it is the same except for the buffer size as I mentionned earlier).
I can't guarantee that the delays are exactly the same... But I'm sure they are at least bigger.
What I actually manage to do with my "µC update method" is :
If the DSP already have selfboot data, I start the DSP with its selfboot, I then pull low the selfboot pin, and send the data that I exproted when I only "Link Compile Download" (with the same method described above), it works, I'm able to download the program in the DSP's RAM... (Which makes me think that the data I send via the µC are reliable)
I guess I'm missing something, but I can't figure out what...
Thanks for your help,
Clement
Hello Clement,
Since you are grabbing only the address and data, the delays will not be labeled and will not have an address of course. So are you converting all of those delays properly?
The data field of the delay is the amount delay in milliseconds as a hex number. So 0xFF is 255ms of delay.
That is the most obvious place to cause an issue is if the delay time is not sufficient for the PLL to lock or for the DSP to start etc.
Have you tried to look at what is being written to the EEPROM? This might shed a clue as to what is happening.
FYI, if you zero out the EEPROM and then let it try to boot up, it will try three times and then fail and go into hibernation mode. You will know the boot failed by reading the Software Panic Value Register address 0xF433, it will have the code 0xBABE if it failed to selfboot. Then you can proceed with the programming. It is good that you are pulling down the Selfboot pin.
Then see what ends up on the EEPROM.
This is a tricky thing you are trying to do so we just have to find the small detail we are missing.
Dave T
Hello Dave,
Sorry for the delay in the response, this development got a bit delayed.
I actually found out what was wrong, I had it almost right at first, it was just that I incremented the write address for 8 bits instead of 32 bits.
Now that I send 4 bytes before incrementing the address, it works perfectly well !
Thanks for your help though, it made me understand a few things I had trouble with.
Best regards,
Clement
Please log in to reply.


