ADAU1701: Readback of MS Signal Envelope

Hello Mark,

Let's start looking into this...

First, the Decaying level you see at startup can very well simply be the DC offset of the ADC converters that is being filtered out by the DC block. I see that also when I use these and when it starts up you get a pop and then the filter starts doing its job and filters out the DC so the level slowly goes down. Try placing a mute right at the ADC input before the DC block and see if this issue goes away.

The second problem is a bit more difficult.

Here is my first hunch...

Something is stepping into the code (the parameters) of one of the envelope generators. I would look for any index selectable cells like a mux or a lookup table. Many of these are not checking of out-of-range values and so will simply write to the offset given even if this points to memory held by another object.

Another way this could happen is with the communications of the host to the DSP. If a memory write is either incorrect or is corrupted upon transmission, then it will write to the incorrect memory location. Since you are using SPI this could happen if the rates are really high and the traces are long or even worse if the SPI lines are going through a wire from another PCB. So if this is a possibility then slowing down the SPI rate might be a good diagnostic test.

If it is possible to stop the host processor and read from the DSP then you can look at all of the parameters of the envelope generator that has "locked up" to see if any of the other settings have changed.

Dave T

Hi Dave

Thanks for the feedback.

Placing the mute (mute active) after the DC block does not eliminate the decaying level. The strange thing I did note is that the decaying level is not always directly after the DC Block; it sometimes occurs further down the audio chain with the readback earlier in the audio chain reporting zero.

Another thought I had:

After reading another post (
https://ez.analog.com/thread/105305-adau1701-dsp-setup-error
) and coupled with the fact that when I removed some of the filters and thus reduce the number of instructions, the glitch / decaying level is vastly reduced to the point where it is rarely seen. Could the fact that my instruction count is so high (992/1024) mean that I am running out of MIPS and the DSP is struggling to process the audio fast enough?

Regarding the second problem, I don't use a mux or lookup table. However your point about writing to an incorrect register is noted; I will double-check my code.

As for my SPI bus, the traces are fairly short (~ 4cm) and I am running the bus at 3MHz. Dropping the speed to 1.5MHz had no discernable affect; the "lock-ups" still occur.

Yes, I can halt the processor and will attempt this & check the register values are not being overwritten/corrupted later this morning.

FYI: In further tests yesterday, I placed two readbacks after the same MS Signal Envelope. I a few instances I saw one readback report zero and the other report 0xFFFFFF. Not sure what this means.

Regards

Mark

Hi Dave

You are not going to believe this - I have found the cause & resolved both issues!

After writing the program & parameter to the DSP (as per function default_download_DSP() from the code generated by Sigma Studio), I had added a check routine to read the first 256 bytes of program memory, just to ensure the DSP initialization had been successful. It was this routine that was the cause of all my problems.

While investigating issue #2, as per your suggestion to check whether the program & parameter RAM had been corrupted, I expanded this check routine to check the entire DSP program & parameter RAM and called it when a readback returned 0xFFFFFF. I noticed that when this check routine was run, a large audio pop was generated, which was quite irritating on the ears. So in the routine I added a write 0x01C0 to the DSP core register (mute the ADC's & DAC's, clear internal registers), then did the validation of the program & parameter RAM, followed by a write 0x01DC to the DSP core register (unmute the ADC's & DAC's, allow signal to pass through DSP core).

After adding the DSP core register writes (to mute / unmute), the problem described in issue #1 disappeared; after a reset all readbacks now report zero, and I have not seen any recurrence of issue #2 problems; all readbacks always report zero.

So thanks for leading this horse to water! Much appreciated.

Regards

Mark

Hello Mark,

That is great news!

Often I have found issues simply by explaining the issue to someone else, anyone, My wife, the kids, the dog! It is then you realize what you are doing wrong or forgot to do. So I am glad I was able to be the dog today!

Your question about the program size, I have found that you can go over 1000 instructions with no issues. Once you start getting closer to 1010 does it start to get iffy. I wish I had a definitive answer to the number of overhead instructions SigmaStudio inserts but I do not. However, with this core, if it runs the program once properly then it will run it that way every time. There are no loops in program execution and no interrupts so it is deterministic.

So what you found is mentioned in the Rams and Registers section of the datasheet in the Direct Read/Write paragraph. Page 30. So you are doing the correct thing.

Also, if you are not using safeload for this core it can be a problem. I think you may already be aware of this but I will mention it for others who may read this.

If you perform a direct read of a parameter in this DSP, the memory is not available to the core during that period of time. There is no buffer or memory controller to prevent contention. So what happens is that either the core is not able to store or retrieve data or the control port is not able to. Depends on who was first. So this DOES lead to clicks and pops in the audio seemingly at random. There are two ways to avoid this that was designed into this core.

The Safeload registers are used for transferring up to five words of data into five consecutive memory locations. This is part of the code that is run as part of the "overhead" code. It will execute these writes to memory at a time when the core is not trying to access memory for the audio program.

Then there are two Data Capture Registers setup such that the core will stuff data into these registers at the proper time during the program execution. These at located at address 0x081A and 0x081B. If you look at the capture window in SigmaStudio when you click "Read" on a readback cell, you will see it uses these registers to gather the data from within the running DSP program. This is why you see a "Read Request" and a "Read Result". The request sets up this register with the program counter address and the register to be transferred and then the read comes back and picks up the result.

Hi Dave

Thanks for the confirmation & info on program size. And yes, I am using safeload to read the DSP parameters.

Thanks & regards

Mark