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.
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.