Booting ADAU1452 using E2Prom.Hex output
Hello everyone,
since we had problems using the C-Source output (data arrays were too big) from SigmaStudio in our microcontroller which boots an ADAU1452 over SPI, we are targeting the use of the E2Prom.Hex output since the code size of this file is much smaller. The format of this file is described in the ADAU1452 datasheet (39pp.).
What we want to archieve:
Embedding the Hex file content to our microcontroller code
Initializing the DSP in SPI slave mode
Preparing a program sequence by stopping the core
Decoding the Hex file and doing on-the-fly block writes to the DSP
Starting the core
Having a parser for the Hex format now, we noticed the following:
Blocks in the Hex file are ordered by the block start address which does not seem to conform to the DSP programming sequence needed
Register block data lengths are always multiples of 4, which can lead to a write to an undefined register address or read-only registers
Can you give us a hint whether an on-the-fly Hex programming sequence will succeed regardless of the notices above?
Is there a smarter way to transfer the Hex file content to the DSP (in SPI slave mode)?
Thanks,
-Thomas
Audio Signal Processors
adau1452
SigmaDSP Audio Processors
Hello Thomas,
You can see the procedure for stopping and starting the core in two places. The first is in the datasheet Table 24 (datasheet Rev C) Example System Initialization register write sequence. The second place is to look at the capture window when you click on "Link/Compile/Download".
Your question:
"Blocks in the Hex file are ordered by the block start address which does not seem to conform to the DSP programming sequence needed"
In what way do they not conform? These files are what is used by the boot-loader built into the part. The file is parsed internally exactly as it appears and the writes are done in the exact order of what is in the hex file. When the core is stopped you can write to any memory in any order. Nothing is running so there are no adverse affects. The only detail is the header. It needs to be written in one write. These are the PLL settings and coefficients so you could cause the PLL to have trouble locking by updating the N/M ratios at different times.
Your second question:
"Register block data lengths are always multiples of 4, which can lead to a write to an undefined register address or read-only registers"
The registers are all 32 bits in length. So four bytes are needed for each register or memory location. So I cannot see where you will be able to write past a memory location into an adjacent location.
Dave T
Please log in to reply.