SafeLoad not working on ADAU1467

Hello Buechlpe,

Can you please attach your project?

I'm not sure about the safeload address, usually it will be the default address shown in the datasheet below.

But your header file shows that's the safeload address, your file seems a little different than the usual files below.

However, the compiler will allocate different safeload address than this default one if the project is quite big. It's rare but possible. So, the new address isn't a problem here.

we can't suspect the SPI communication, since your normal read and write are perfectly working.

I will have a look if you send your project.

Is your project so big that uses so many filters?

Regards,

Harish

Thank you for your quick response.

Unfortunately, the project file cannot be shared publicly. Is there any chance to make the project file available to you on a private channel?

The project uses almost the entire resources of the DSP and includes 26x 5-band filters in addition to many other features.

Hello Buechlpe,

You can PM the project to me. Make sure you send a friend request so that I can respond to your private message.

Regards,

Harish

Hi Buechlpe,

I also have a project using a part in the same family ADAU1466 and had the same issue at first. This may or may not be what's happening for you but for me I wasn't sending the three writes correctly as described in the datasheet in the portion that Harish shows in the post above.

It is also important to write to the addresses that it shows in that table and yours look different as he mentioned. So for me after sending the following in the correct order, it worked.

1.) Send the coefficient data payload to safeload addresses 0x6000-0x6004

2.) Send the target address of the filter you want to update to safeload address 0x6005

3.) Send the number of words to write (aka number of coefficients that are being updated) to safeload address 0x6006

That last step is important because that triggers the update. Hope this helps.

-Alex

Hello Buechlpe,

Since your project uses 95% of resources, the memory is also occupied a lot. The usual safe load memory is used for storing other parameters, so the compiler allocated different memory for the safe load operation.

above marked is the usual default safe load address (if the project is small or medium). This is a just an info on memory allocation of your project.

So, I will try to use the new safe load address shown in the text file and get back to you.

Regards,

Harish

Hello Harish,

Thank you for your support.

I’ve tried using both the default address from the datasheet and the one provided by the compiler. I attempted writing all registers in a single step, grouping them as suggested by Alex, and even writing each register individually — unfortunately, none of these approaches worked.

I’m looking forward to hearing about your results.

Best regards,
Peter

Hello Peter,

You shouldn't just use the default address given in the datasheet, in most cases, that address (0x6000) will be the safeload address, but not always. There are exceptions with bigger projects like yours. So, you MUST use the address given by the compiler (mentioned in the capture window/param.h file).

You must take care of the second page enable register 0xF899, when your parameters are in lower memory, then you should make sure that the value of 0xF899 is set as '0' and for upper memory the value of F899 is '1'.

Page 1 (lower)

page 2 (upper)

Today, I just compiled one of your projects with some minor changes with the input/output just to make it compatible with my Evaluation board's input/output. My signal flow is an input passing thru the filter and then to the output.

I used SS at that time, when changed a parameter of the filter, my capture window gets updated like below. This filter parameter (5 coefficients) resides at the address from 0x54DD to 0x54E1.

It does seem like SS is directly writing to that exact address, but it doesn't. It hides the actual safeload operation from the capture window.

My safeload address from param.h file and capture window is below.

I probed the slave control port to see what it is actually sending out. When I changed a parameter (by changing the frequency by clicking the arrow next to input box) I initiated a single safeload operation.

I can see that the safeload is done at the address given by the compiler which is from 0x54C1 (21697) thru 0x54C8 (21704).

In your attached file above (my file too), I can only see up to the 'target address holde'r register which is 0x54C6 (21702) in my case.

But there are two more registers to take care of, which is used to trigger the safeload operation. Here you are triggering 5 writes (5 coefficients),

So, you should write '5' to 0x54C7 (21703), if you are writing to lower memory (or)

you should write '5' to 0x54C8 (21704), if you are writing to upper memory.

If your parameters are in upper memory, then you can write '0' to 0x54C7 and '5' to 0x54C8 (just to maintain the burst write)

SS does all this perfectly, I probed the signal and verified it with your project. So, it always works when doing with SS. Your controller code should do the exact same for this to work. Make sure this is all done in your code.

I hope my explanation is clear, I will get back to you with some more info if possible.

Regards,

Harish

Hello Harish,

Thank you for your extensive testing. I’ve found the solution to my problem.

According to the header file exported by SigmaStudio, the SafeLoad registers are located on the second memory page (page 1).

However, in SigmaStudio I can observe that memory page 0 (the first page) is actually being activated.

If I adjust my code accordingly and select page 0 — contrary to what the header file indicates — SafeLoad works perfectly.

Best regards,
Peter