I2C Safeload problem on ADAU1452

Hello logoho,

The Safeload register is located at the start of DM1. Which starts at address 0x6000. So try that offset. 0x6005 for the target address and 0x6006 for the trigger/number of parameters.

FYI, you do not have to use safeload for wending Mutes with the ADAU1452. The SigmaStudio code was written for the earlier SigmaDSP processors that had to use safeload to prevent issues with the core reading memory at the same time. We improved it for the ADAU1452. You need to use safeload for loading filter coefficients. 

Let us know if this solves your issue. 

Dave T

Hello,

thx, that solved our issue with the safeload I2C communication!

Could you explain which memory access is best fitted for which parameter access.

If I understand it correct there are "3 modes":

• Safeload: will copy data only between audio samples to avoid clicks
• Direct parameter access: access any parameter any time - could cause audio distortion/clicks
• Indirect parameter access: same as direct access, but compiler does not change the address and therefore the uC code stays the same (can be accessed with safeload)

We will control a mute, a volume and later on also FIR and maybe IIR filter coefficients. It would be helpful if you could advise which memory access would be best fitting for each parameter and why this is so.

Kind regards

Hello logoho,

First I need to start out by mentioning that this applies ONLY to the Sigma300/350 cores. This would be the ADAU1452/51/50 and the ADAU1462/63/66/77 processors. Our older cores were not as advanced and you had to safeload everything to prevent clicks and pops. 

These newer cores have an arbitration feature that prevents problems when accessing parameter memory within reason. If you have to send large amounts of data then you should use safeload or mute when doing it. I am talking about large FIR filters, like 1024 taps etc. If you update an FIR filter you need to mute it anyway. 

If your application is not terribly time sensitive then you can still use Safeload for updating mutes and volumes if it makes your software simpler. There was one user who had to update a large number of volume controls using I2C and using Safeload would have taken too much time. So he used Direct access with no problems. 

The next thing I want to say is that there is not too much difference between Safeload and Indirect Parameter access. They work pretty much the same way.

Safeload: You load in the data and the start address and then the number of bytes to trigger the transfer.

Indirect Parameter Access: You load in your data into the fixed address for the parameter, and then you load in the start address of the first parameter and the number of parameters to trigger the transfer.  

They function in the same way. The Indirect Parameter Access Table allows you to FIX the addresses of the desired parameters so you do not have to know where the compiler had placed them in memory. If you do not use the table then you have to recompile your controller code with the updated addresses every time you make changes in the program flow in SigmaStudio. 

ALL filters need to use either Safeload or the Indirect Parameter Access Table. If you directly write to a filter coefficient and it happened to occur over several sample periods ( and it will most likely happen) then the combination of old and new coefficients can result in an unstable filter for a few samples which is not good!

FIR filters tend to be larger than just five words so updating FIR filters require a little more care. For the FIR filters there are several strategies. For the stream based processing, which is the standard SigmaStudio programs, you should mute the audio while updating the filter coefficients and then unmute when done. If you cannot withstand a mute in your application then you can implement two filters with a switch between them. So you are hearing one filter while updating the other off-line filter and then activate the switch to the new filter when done. This uses more memory and processor resources. If you are using Block processing instead of the stream based processing, then you have to mute the filter, update it and then wait for the filter to flush before unmuting. 

So FIR filters can be another discussion. 

All the other parameters can usually be changed directly. Most of them that you change during operation you will most likely use the slew versions so that helps make the changes smooth. Updating compressors can take some time but is usually not a problem for clicks or pops unless it is a drastic change. But, using Safeload would have the same effect. 

All the register settings are safe to directly change of course. Just be careful switching data sources and clock settings etc. 

Reading any memory location will never cause a conflict with the core having access. Only writing to memory. 

Again, this is only for the Sigma300/350 cores. The older processors will have issues with direct access. 

Dave T

Hello logoho,

First I need to start out by mentioning that this applies ONLY to the Sigma300/350 cores. This would be the ADAU1452/51/50 and the ADAU1462/63/66/77 processors. Our older cores were not as advanced and you had to safeload everything to prevent clicks and pops. 

These newer cores have an arbitration feature that prevents problems when accessing parameter memory within reason. If you have to send large amounts of data then you should use safeload or mute when doing it. I am talking about large FIR filters, like 1024 taps etc. If you update an FIR filter you need to mute it anyway. 

If your application is not terribly time sensitive then you can still use Safeload for updating mutes and volumes if it makes your software simpler. There was one user who had to update a large number of volume controls using I2C and using Safeload would have taken too much time. So he used Direct access with no problems. 

The next thing I want to say is that there is not too much difference between Safeload and Indirect Parameter access. They work pretty much the same way.

Safeload: You load in the data and the start address and then the number of bytes to trigger the transfer.

Indirect Parameter Access: You load in your data into the fixed address for the parameter, and then you load in the start address of the first parameter and the number of parameters to trigger the transfer.  

They function in the same way. The Indirect Parameter Access Table allows you to FIX the addresses of the desired parameters so you do not have to know where the compiler had placed them in memory. If you do not use the table then you have to recompile your controller code with the updated addresses every time you make changes in the program flow in SigmaStudio. 

ALL filters need to use either Safeload or the Indirect Parameter Access Table. If you directly write to a filter coefficient and it happened to occur over several sample periods ( and it will most likely happen) then the combination of old and new coefficients can result in an unstable filter for a few samples which is not good!

FIR filters tend to be larger than just five words so updating FIR filters require a little more care. For the FIR filters there are several strategies. For the stream based processing, which is the standard SigmaStudio programs, you should mute the audio while updating the filter coefficients and then unmute when done. If you cannot withstand a mute in your application then you can implement two filters with a switch between them. So you are hearing one filter while updating the other off-line filter and then activate the switch to the new filter when done. This uses more memory and processor resources. If you are using Block processing instead of the stream based processing, then you have to mute the filter, update it and then wait for the filter to flush before unmuting. 

So FIR filters can be another discussion. 

All the other parameters can usually be changed directly. Most of them that you change during operation you will most likely use the slew versions so that helps make the changes smooth. Updating compressors can take some time but is usually not a problem for clicks or pops unless it is a drastic change. But, using Safeload would have the same effect. 

All the register settings are safe to directly change of course. Just be careful switching data sources and clock settings etc. 

Reading any memory location will never cause a conflict with the core having access. Only writing to memory. 

Again, this is only for the Sigma300/350 cores. The older processors will have issues with direct access. 

Dave T