Intermittent Safeload failure ADU1701

I’ve implemented a 5 band peaking equalizer using the ADU1701.  The ADU1701 interfaces with a microcontroller via SPI.  Using the safeload mechanism, updating coefficients of each band works most of the time(approx. 90%).  However, there are occasional safeloads that result in unexpected behavior – scrambled sounding audio or no audio output.

After a safeload in which the filter fails, reading back coefficients from parameter ram reveals a mismatch.  I’ve only ever detected one out of the five coefficients showing a mismatch with what was sent by the microcontroller, and it is never the same coefficient.  Moreover, the mismatch parameter ram value appears to be of the previous filter configuration.

My firmware waits for the IST bit to clear before initiating a safeload.

The last paragraph on page 35 of the ADU1701 datasheet reads:

“When the initiate safeload transfer bit is asserted, only data from those two registers are sent to the RAM; the other three registers are not sent to the RAM and may hold old or invalid data. “

This is precisely what seems to be happening in my application except I’m updating all five coefficients.

Beyond waiting for the IST bit to clear, is there anything more I can do to reach a 100% safeload success rate?

Would writing zeros to the safeload data ram before writing the new coefficients help?  

Does it matter which order you update the safeload address / data registers?

Thanks in advance for your help.

  • I tried a really simple project that changes the parameters for a basic filter. I used an I2C bus sniffer to see exactly what SigmaStudio was writing. Here's the exact output, with my comments. The first two bytes for each line are the address bytes.

    //Write 1kHz, +5 dB peaking filter coefficients

    08 10 00 00 83 57 7E     //Data 0
    08 15 00 00              //Address 0
    08 11 00 FF 0A B4 47     //Data 1
    08 16 00 01              //Address 1
    08 12 00 00 74 12 18     //Data 2
    08 17 00 02              //Address 2
    08 13 00 00 F5 4B B9     //Data 3
    08 18 00 03              //Address 3
    08 14 00 FF 88 96 6B     //Data 4
    08 19 00 04              //Address 4
    08 1C 00 3C              //Set IST High

    Check this against your code to see if you're doing the write the exact same way.

    The project file is attached for your reference.

  • 0
    •  Super User 
    on Jan 13, 2013 2:22 AM

         Brett,

         Your example above with the sniffer turned out to be the most useful of all the many threads on the elusive knowledge of safeloading a -1701.  It clearly shows the actual byte-by-byte transfer that a programmer needs to implement -- nothing more or less.  In our case my friend MikeB (who does our PIC-C coding, PCB layouts, and just about everything that makes stuff work) was surprised to see the extra "00" byte included in every data word:

    After all, aren't parameters 28-bit + "0000" to make a 32 bit (four byte) word, not the five bytes showing after the address?  The mystery cleared up when he read in the friendly data sheet that yes, this zero byte is in fact required:

    Mike posted a safeloading question a few days ago, then we yanked it after he found the above answer.  Now with that zero byte in his code, our bi-quad filters are accepting updates and behaving themselves.

         Here's what I find a bit puzzling:  Why the extra byte?  For example it could allow for the five bytes of an instruction word, except that instruction safeloads aren't supported anyway.

         It's quite unfortunate that your post is buried in a tangentially related discussion, thus going unnoticed near the bottom of any search we tried.  This example deserves to be in a FAQ or even in the data sheet!

         Thanks as always for your helpful attention to the forum.

         Bob

  • Thanks Bob. I'll make an FAQ about this right away. It should definitely be featured more prominently.

  • Hi Bob,

    Also, to answer your question... the extra byte of zeros was originally included when the safeload function was designed to handle a 5-byte instruction word, but it was eventually decided that the user shouldn't be messing around with the program RAM during run time. So, the 5-byte option was dropped, but the unused byte remained in the safeload protocol. I hope that makes sense.