ADAU1467 Program RAM data issue
Background
We are programming the dsp using data stored on external flash. Since our mcu does just have a small amount of ram and internal flash, we need to transfer the dsp program from external flash to dsp in small portions (typically 128 bytes). However there seems to be some issue in writing the Program RAM data in parts instead of as a large chunk of data (eventually it also affect DM0 and DM1 data).
Test on adau1467 eval board
As a test we have used the system files output from SigmaStudio 4.2. One of the header files, Test_IC_1.h, have all the register data, but let's focus on DSP Program data. First we test to write the content using default_download_IC_1(). Works without any problems (audio out). In order ti simulate flash transfer, we split up program data in two vectors. For example, the size of 624 bytes is split into two vectors of 512 and 112 bytes and the start address of the 112 vector is incremented by 512 (vector size of the 512 vector). After download no audio out. Everything looks as expected on logic analyzer. The delay between end of first program block and start of the second program block is ~0.5ms (we are using i2c as protocol). ACK received from dsp for all transfers.
This is a real show stopper for the moment so I hope that there is something I forgot do do when I write program data to the dsp.
Default Test_IC_1.h:
/* DSP Program Data */
#define PROGRAM_SIZE_IC_1 624
#define PROGRAM_ADDR_IC_1 49152
ADI_REG_TYPE Program_Data_IC_1[PROGRAM_SIZE_IC_1] = {...}
...
void default_download_IC_1() {
...
SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, PROGRAM_ADDR_IC_1, PROGRAM_SIZE_IC_1, Program_Data_IC_1 );
...
}
Test_IC_1_modified.h
/* DSP Program Data part 1*/
#define PROGRAM_SIZE_IC_1 512
#define PROGRAM_ADDR_IC_1 49152 //c000
ADI_REG_TYPE Program_Data_IC_1[PROGRAM_SIZE_IC_1] = {...} //first 512 bytes
/* DSP Program Data part 2*/
#define PROGRAM_SIZE_IC_2 112 //512+112=624
#define PROGRAM_ADDR_IC_2 49152+512
ADI_REG_TYPE Program_Data_IC_2[PROGRAM_SIZE_IC_2] = {...} //last 112 bytes
...
void default_download_IC_1() {
...
SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, PROGRAM_ADDR_IC_1, PROGRAM_SIZE_IC_1, Program_Data_IC_1 );
SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, PROGRAM_ADDR_IC_2, PROGRAM_SIZE_IC_2, Program_Data_IC_2 );
...
}
Test_IC 1.zip
Audio Signal Processors
programming
flash
system_files
adau1467
SigmaDSP Audio Processors
Show More
Hello alexjaw69,
I think I may see where the problem is. If you are simply dividing up the EEPROM program data into chunks then writing it this will fail.
You must first write to the PLL registers and setup the PLL and the clocking for the part. Then wait until the PLL is locked. Before this time the memory is not accessible. Then you can start writing the program into program and writing the parameters into the data memories.
Look at table 19 in the datasheet.
After this, you can write things one word at a time if you like. You cannot split up a 32 bit word so you have to be aware of this. The registers are 16 bit. So if your split of data goes across a word then that will be a problem. Most EEPROMS are byte level devices from what I know.
Dave T
All dsp programming is performed by execution of default_download() which is created by SigmaStudio, i.e. programming does exactly the same thing (data wise) as if done through download in SigmaStudio. In the test, the only thing different is that one of the vectors (Program_Data) has been divided into two parts and an additional SIGMA_WRITE_REGISTER_BLOCK() has been added to default_download(). The '...' marks meant all the other instructions in SigmaStudioFW.c unchanged.
The split is 624 into 512 and 112, i.e. aligned with 32 bits.
Actually, it's possible to show this using Sequence window in SigmaStudio. I took the content from the Capture window and pasted it in the Sequence window. Saved it and used Notepad++ to edit the xml sequence file. I did the split of Program Data, maintaining 32 bit alignment. Loaded the modified sequence file and downloaded it with SigmaStudio - no audio anymore.
Tested also with DM0 and DM1 data. Same effect for DM0 but DM1 was unaffected by a split. I really need to understand why it's not possible to split program and dm0 data (keeping correct incrementation of addresses and 32 bit alignment)
Attached the sequence files
Test_download_seq_files.zip
Hello alexjaw69,
There is an issue that we will be fixing in the next revision but your program is small and should not be running into it. The issue is that the XML files do not list what page of memory it needs to write to. There is an upper and lower page of all three memories so you need to know this info if you have to use the upper memory.
The files you sent are small and the fact that you can correctly write the entire file but not in pieces means this is not the issue.
Have you looked at the DM0 in the Params window to see if it is loading in correctly or if something is slightly off? You can load it in and the refresh the view to see what is in memory. You will have to use the Compile/Link/Connect button instead of the download.
This may give a clue as to what is going wrong. I did not see an issue with the XML files. It looks like it should work fine.
Dave T
I met the same issue at the customer side, finally, I found that this is caused by the RAM addressing. Take your program ram split-sequence file for example, change the address of the second block from C008 to C002, you will get the correct result. It seems the address is recognized as word address. I was using ADAU1452, hope this works for ADAU1467.
Please log in to reply.