How is SafeLoadModule activated for ADAU1466?
I have a processing scheme for the ADAU1466. I export the files in C with the Export System Files button and in the parameters file I have the following:
/* Module SafeLoadModule - SafeLoadModule*/
#define MOD_SAFELOADMODULE_COUNT 1
#define MOD_SAFELOADMODULE_DEVICE "IC1"
#define MOD_SAFELOADMODULE_NUM_SAFELOAD_ADDR 0
The registers defines for the secure transfer do not appear. How do I make them appear? With other DSPs I have never had to do anything, they always appeared here.
I'm using version 4.0 of SigmaStudio. I've also tried it with version 3.17.
Example for ADAU1452
/* Module SafeLoadModule - SafeLoadModule*/
#define MOD_SAFELOADMODULE_COUNT 7
#define MOD_SAFELOADMODULE_DEVICE "IC1"
#define MOD_SAFELOADMODULE_DATA_SAFELOAD0_ADDR 5032
#define MOD_SAFELOADMODULE_DATA_SAFELOAD1_ADDR 5033
#define MOD_SAFELOADMODULE_DATA_SAFELOAD2_ADDR 5034
#define MOD_SAFELOADMODULE_DATA_SAFELOAD3_ADDR 5035
#define MOD_SAFELOADMODULE_DATA_SAFELOAD4_ADDR 5036
#define MOD_SAFELOADMODULE_ADDRESS_SAFELOAD_ADDR 5037
#define MOD_SAFELOADMODULE_NUM_SAFELOAD_ADDR 5038
Thanks for the help
Carlos.
Audio Signal Processors
adau1452
SigmaDSP Audio Processors
safeloadmodule
adau1466
safe load module
Show More
Hello Carlos@lynx,
Sorry for the delay.
It appears that this is a case of the feature not keeping up with the ability of the processor. The export tool clearly needs to be updated and I will put in a request to get that done.
Meanwhile, you will have to manually add this address to your controller code but it is not as bad as it may seem.
In the recent revisions of SigmaStudio we have fixed the safeload address so that it never moves when you edit the project and recompile. It is always at the start of DM0. In the datasheet you will find a table describing the addresses. Here is a screenshot of the table:
The Sigma350 is a little different from the Sigma300 or other earlier processors. Since there are additional pages of memory, the safeload module needs to know where to put it. Which page of memory?
So the data goes into the start of DM0, address 0x6000 - 0x6004.
Address 0x6005 is where you place the target address, (so far this is the same as older processors)
Now there are two different locations for the number of words to write/safeload trigger. You leave one of them as zero but you write the number of words into 0x6006 if the object resides in the lower memory and 0x6007 if it resides in upper memory.
So your controller will need to keep track of which page all the objects are residing in.
Eventually this will be fixed. I am not certain when, I know it will not make the new release due at the end of this month.
Thanks,
Dave T
Hello Carlos@Lynx,
I have been notified that this bug has been fixed and will be included in the SigmaStudio Rev 4.2 release.
Thanks for reporting the problem and sorry for the inconvenience.
Dave T
hi DaveThib,
1. When is ADI able to release SigmaStudio Rev 4.2, is there a time?
2.The Limiter module is a bit of a problem in ADAU1466, as follows:
error (42,Limiter 1): offset value "55847" out of range [-32767, 32767] in module limiterAlgS3001 (7533,0)
##### Compile FAILED: 1 errors, 0 warnings #####
I hope to get your answer, thank you
Like Y
Hello ymwlike,
I was recently told that it is due to release around the end of August. Exact date I do not know.
Regarding the limiter module. This is new to me.
Can you please come up with a SigmaStudio project that shows this error without giving up any of your proprietary program and post it in a new thread? This is a different topic so it should be on its own thread.
I would like to try to reproduce this problem here first.
Thanks,
Dave T
hi DaveThib,
Of course no problem,I also hope to get settled earlier.as follows:
Thanks,
Like Y
Hello Like Y,
Can you attach the actual project? To do this on the forum you need to click on the upper right of the reply window on the "Use Advanced Editor" link.
That editor will allow you to attach the project file.
Thanks,
Dave T
hello Dave T.
OK,Already uploaded.
Thanks
Like Y
Hello Like Y,
There does seem to be a problem in the compiler. The pointers to memory are being corrupted somewhere when the memory cell that is using memory DM1 is set to a large number. It is clearly not too large and there is enough memory for the delay but it is somehow causing an issue. There seems to be a work-around. I found that setting the max delay time to 32757 fixes it in this particular program. In your full program it might have to be a lower number.
I will report the error, and I do know there has been some bugs with using the extra memory of this newer device, so I suspect that this is already a known issue and will be fixed in the upcoming SigmaStudio update.
Dave T
hello Dave T.
When the DM1's memory uses a large number, an error occurs as follows:
Like Y
Please log in to reply.





