IIR filter crashes on the fly

Hello Dan,

I like your user interface (real analog knobs to control analog functions). From your description, it appears that the microcontroller is regularly monitoring its ADCs (thus, the pot positions). Any change triggers software that looks up and/or calculates new filter coefficients, then safeloads them. From here it's hard to discern what might go wrong, but I'll hazard a guess:

It could be that noise on the pot ADC inputs is confusing the uC. For example, suppose that pot noise interrupts the change routine with a new request while it's busy safeloading a previous set of coefficients. This breaks the normal I2C sequence at the DSP, which in turn may cause it to ignore further loads. If this were the case, it could be fixed by masking interrupts during the safeloading procedure. Of course, your actual issue may be something entirely different, and someone smarter than me with this uC stuff could ask the right questions to narrow it down. What my experience tells me is, 1. Computers cause trouble, and 2. Computers talking to each other is double trouble.

A computerized system must maintain its integrity in the face of any reasonable event -- whether it's controlling a stereo or (gasp!) a radiotherapy machine. Every embedded systems engineer should read this famous account of what might happen otherwise; Therac-25 - Wikipedia, the free encyclopedia

Hello Awesome Bob,

Thanks for the compliment. Actually, this is what exactly we talked about a few months ago as I have finished the hardware for this project. https://ez.analog.com/message/138733#138733 . I have decided to try the IIR instead of the state Q/F filter for the reason you have suggested - IIR lets you having more precise control over the response you desire but is more complex to implement, while the state Q/F filter is more of like difficult to tame but is straightforward and is comfortable to use. So I took the challenge and go for the IIR! Well, I guess I have bitten more than I can chew.

As I have investigated further, the process of I2C communication is correct, as I have masked correctly the interrupts during the transfer process. All the data calculated and transferred are correct and are recognized by the DSP. Now, the mystery is that the IIR filter block seems to ignore the calculated values from the uC. I have tried to "pre-calculate" several values from the excell sheet you have provided, load them via SigmaStudio and export the equivalent hex format to the micro. Well, the IIR "responds" to such "pre-calculated" values from SigmaStudio! How is that? I honestly don't know. Do I have the correct hex format transferred to the IIR? YES! I have verified it using a console and a logic analyzer. I think the "numbers" calculated by the uC is the main 'suspect' here. Do we have a way to verify if the values loaded are understood by the IIR block? The number format I use here is 5.23.

On the other hand, I also tried the state Q/F filter on my design and implemented part of the algorithm you have provided me as an example. It works perfect! This maybe as for the moment the solution I will turn into so as to meet the deadline I'm after at.

P.S. Thanks for the historical perspective, It's nice to know stuffs like that. A gentle reminder of how critical good software practice is.

Best Regards,

Dan

Hello Dan,

Thank you for your kind reply. It appears you have the microcontroller end of things well in hand. Thus your safeloading routine is operating consistently as you have verified. There's one other detail that just came to mind now. It gave my friend and I fits when we first attempted to safeload a -1701, so perhaps it's causing your difficulty as well.

Although each filter coefficient is four bytes (28 coefficient bits with four zeros on top), we actually need to safeload five bytes per coefficient -- another full byte of padding on the MSB end. Though this is shown in Table 30 of the ADAU1701 data sheet, it can easily be overlooked:

If my memory serves me, Brett G. once described the reason for this (although I can't find the link) -- early in the -1701's design, this extra byte was reserved to allow the safeloading of five-byte program instructions as well as the four-byte parameters. Programming on the fly was dropped, but the zero byte remains.

The IIR filter itself will happily go through the motions of multiplying / delay / adding with any coefficients we send it. If you send merely incorrect coefficients, a grotesque response results. Missing that zero byte in the safeload sequence, however, prevents each new coefficient from loading. Inserting this byte if missing, will likely bring you home.

Best regards,

Bob.

Hi Dan,

Did you get your -1701 to safeload your filter coefficients?

Bob

Hi there,

Did you try to read the coefficients back from the DSP after writing them to see if they are what you intended.

Seems like you're doing everything right, but the DSP seems confused. I don't know which registers to read, but you may try reading after writing just to check.

Sorry to mention anything that you have already done

Dear Bob,

Sorry for the late response. I've been on vacation for a month.

I have abandoned the IIR implementation and went through the State Q filter as it was a bit easier to do. It went fine and was shipped to the customer. However, I haven't solved the problem yet on this issue. So yes, unfortunately this case is still open. Yes, I did the 5-byte safeload mechanism as suggested from the datasheet but still it doesn't work.

Dear atembedded,

Thanks for the suggestion. I did what you said, the numerical value on the DSP readback is exactly that of the 5-byte hex format equivalent. So things get more weird at this stage!

I think I ran out of options at this time I could not think of any experiment that would lead me closer to the answer.

Thanks for the support, though.

Best regards,

Dan

This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

Thank you,
EZ Admin