DSP readback addressing

HI Dragoimir:

There is a new feature introduced on the Sigma300/350 (ADAU145z, ADAU1463), called indirect parameter table. It allows users to indirectly read or write parameters from the schematic on a fixed address table. I think this is what you are looking for.

Forcing the linker to place all parameter continuously is not possible since the linker prioritizes the signal flow 1st, followed by the order in how the users instantiated their modules within the signal flow.

Hope this helps.

Regards

Miguel

Hello Dragomir,

Here is where you will find the instructions on how to use the table:

https://wiki.analog.com/resources/tools-software/sigmastudio/usingsigmastudio/indirectparamaccess?s[]=indirect&s[]=parameter&s[]=table

Dave T

Thanks Dave and Miguel,

this is a nice feature, i'd to build an utility to do part of that job in renaming the safeload start address during microcontroller code compilation (i use more than one dsp and sstudio emits the same define name for both the starting addresses, so i had to rename it IC1_SAFELOAD_START and IC2_SAFELOAD_START and so on )

Please, allow me a couple of other questions.
Since i'll have to read it quite often (24/7 at about 50mS rate), will be any impact on performance ? (clicks, pops, any other nastiness)
Using the indirect addressing will consume more operations in program memory respect to the standard readback block ?

Messing with the "advanced framework configurations", i see two other features:

"Enable framework update to avoid panic error caused by program memory (From sigma studio 4,0)"
"Enable malloc and free bug fixes in the block processing mode".

Please tell me more about the first one:
i think i'd implemented the software download pretty well, the micro downloads the code into the dsps then start monitoring them,
continously looking at the core run register and panic flags.

Sometimes all is fine, sometimes i get the nasty PM1 panic flag on (i get the same if i download the code through sigmastudio): the difference between "all is fine" and "panic flag" could be a recompilation of the dsp code (first test -> no panic flag, recompiled -> panic flag, recompiled again with some modifications -> no panic flag).

Since i have no idea why the "PM1 panic flag" sometimes pops up, i'm asking if this new feature will address this problem
(i also read some posts here where some users recommend to clear the memory on startup because its not guaranteed to be so).
I've to complete this project in few time, it is intended to be running 24/7 and this "PM1 panic" puts me in panic as well.

Regards.

Addendum:
having turned on the indirect addressing, now SigmaStudio also zero-fills the DM1 memory area itself.
The dark side of this is that now the dsp code is grown about 80KB: i've three dsps so i get >240KB of wasted space
on the microcontroller for the DM1 zeroing, moreover the compiler seems does not allow for tables >65535 bytes.
I can patch the sigmastudio generated code to remove the biggest "zero" part of this section, since it won't fit into the micro
flash, but i am curious about the very last value written at address 45055 (0xAFFF):

/* DSP Ram Data */
#define DM1_DATA_SIZE_IC_1 81056
#define DM1_DATA_ADDR_IC_1 24792
ADI_REG_TYPE DM1_DATA_Data_IC_1[DM1_DATA_SIZE_IC_1] = {
0x00, 0x1B, 0xB1, 0x6A,
0xFF, 0xD2, 0x1D, 0xB5,
0x00, 0x1B, 0xB1, 0x6A,
0xFF, 0x00, 0xEB, 0xFC,
0x01, 0xA0, 0x0F, 0x7E,
0x00, 0x00, 0x00, 0x00,
..... // >> '0x00, 0x00, 0x00, 0x00,' repeating 20500 times
0x00, 0x00, 0x00, 0x03, // <<--last line, address 0xAFFF
};

Why this value is not 0x00, 0x00, 0x00, 0x00, ?

I would modify the dsp loading routine like this:

(pseudo code)
...
SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, PARAM_ADDR_IC_1, PARAM_SIZE_IC_1, Param_Data_IC_1 );
SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, DM1_DATA_ADDR_IC_1, DM1_DATA_SIZE_IC_1, DM1_DATA_Data_IC_1 );
_ZeroFill(DEVICE_ADDR_IC_1,DM1_DATA_ADDR_IC_1+ZeroFillBegin,ZeroFillLength);
_Add_The_Last_Word(DEVICE_ADDR_IC_1,0xAFFF,TheNonZeroValueAtAFFF,4);
SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, REG_KILL_CORE_IC_1_ADDR, REG_KILL_CORE_IC_1_BYTE, R59_KILL_CORE_IC_1_Default );
...

The question is (linked to the one above): what is the meaning of the value written at 0xAFFF, and have i to put it back there ?

Could it be possible to have the sigmastudio generated code including this modification ?
(have no 80KB of zeros into the table, but a call to a routine which writes 80KB of zeros instead).

Regards.

Addendum++:

The DM0 memory zerofilling is due to the version control enabled: values at 0xAFFF and 0xAFFE are the version numbers (major and minor).
Nothing changes in DMx array length turning on the "Enable framework update to avoid panic error caused by program memory (From sigma studio 4,0)", and having it either on or off, seems to have no effect on panic flag status.
I can have (not always) PM0 or PM1 panic active, and it cannot be reset, no matters if i i load the firmware through sigmastudio or the host microcontroller, with or without the "Enable framework update to avoid panic error caused by program memory (From sigma studio 4,0)" option turned on.
Would be nice to have an explanation about this.

Regards.

Hello Dragomir,

You have asked a lot of questions... Let me start with the Panic Error Flag.

This is caused by the look-ahead cashing of instructions. When it reaches the end of the code the cashe is not smart enough to know there will be a jump command. So it fetches past the end into uninitialized program memory. Then if it happened to have random data in it and the parity bit is not the same as the parity of the garbage, then it triggers the flag. The compiler was adding two zero words to the end of the program to clear it out but it was not enough. I discovered that there are some instances where the pre-fetch gets more than two instructions. So the fix was to add three zeros. That is what you are enabling. It will change the size of the EEPROM image but only by a few bytes.

From my tests here I have found that I have to clear the errors after loading the program. So once the program is running you should clear the error and then start checking. By the way, do you know that you can tie that flag to a GPIO pin and have it signal the system controller to poll the error codes? This way you do not have to poll that often for reading the error panic flag.

For the table. You do not have to use the indirect addressing that it uses. It is handy for filters but not needed for any other reads or writes. Unless you really want it in between frames. What you can do is use the table to give you the address of the parameter and then your controller can directly write to the parameter. The table will help you keep the location of the parameters. When initializing after startup you can read the table and get the offset to find the address. Then load the address into your controller's memory and have it use that address.

Your question about access to memory causing clicks/pops. No, it will not in these generations of SigmaDSP. The Sigma300/350. Accessing memory from outside the DSP does not stop the DSP from access to RAM. Should the unlikely situation happen where you are writing to the same address at the same exact time, then the core will wait one core clock cycle and then perform the write. This will add one clock cycle to the frame but usually this is not a problem since most programs are not 100% full with no spare cycles.

Dave T

Very good Dave,
many thanks for your answers.

DaveThib said:
This is caused by the look-ahead cashing of instructions. When it reaches the end of the code the cashe is not smart enough to know there will be a jump command. So it fetches past the end into uninitialized program memory. Then if it happened to have random data in it and the parity bit is not the same as the parity of the garbage, then it triggers the flag. The compiler was adding two zero words to the end of the program to clear it out but it was not enough. I discovered that there are some instances where the pre-fetch gets more than two instructions. So the fix was to add three zeros. That is what you are enabling. It will change the size of the EEPROM image but only by a few bytes.

Right, i see, enabling "Enable framework update to avoid panic error caused by program memory (From sigma studio 4,0)" causes three zeros added to the end of program memory.

DaveThib said:
From my tests here I have found that I have to clear the errors after loading the program. So once the program is running you should clear the error and then start checking. By the way, do you know that you can tie that flag to a GPIO pin and have it signal the system controller to poll the error codes? This way you do not have to poll that often for reading the error panic flag.

Yes i know this, and i'm resetting the panic flag as well, once the dsp is loaded and started.
Polling for panic flag is done in 1 second timing, audio levels readout is done every 50mS and the indirect addressing is used for this, because the readback addresses are often not continous, so i cannot place a multibyte read; i can surely use the GPIO to read the panic flag, but the "big stuff" is the levels reading.

Maybe i 'll have other questions on the panic flag in future but, at this time, please tell why there's PM0 and PM1 panic ?
I see there 's one Program Memory, so what's the difference ?

Best regards.

Hello dragomir,

These big complicated chips are designed now in a similar way to SigmaStudio. There are blocks that are inserted and connected then that is used to layout the part. So the memory comes in smaller blocks that are put together to make larger blocks. The panic codes were setup by the designers and they wanted to know which sub-block in the larger block of memory is having a problem. Unfortunately, then we cannot just combine it back to one PM-Panic code. So there are two blocks but it is one large block of memory from the DSP and comms port point of view. The ASRCs are more of the confusing ones. I tried to explain the difference in the names in the new revision of the datasheet but it is still confusing.

So you are still getting PM0 or PM1 panic codes? Even with the framework option checked off?

So for your meter levels. You can use direct addressing. Just pick up the location of the meter in the table and then directly address it and do not use the full functionality of the table to indirectly address it. Only use that for changing filters.

Dave T