I am using an ADAU1701 to implement a four channel audio mixer. The first two input channels are routed to the DSP's ADC0 & ADC1, the second two input channels are routed to the DSP's SDATA_IN0 via an external ADC. A fifth internal DSP input channel may be selected from either pink noise or sine tone. The input stage (shown below) depicts the MS Signal Envelope / Readback block used. The mixer & output stages (not shown below) contain more MS Signal Envelope / Readback blocks, for a total of 12.
The DSP is compiled for a 48kHz sample rate with PLL_MODE1 tied high and PLL_MODE0 tied low.
Number of instructions used (out of a possible 1024 ) = 992
Data RAM used (out of a possible 2048 ) = 425
Parameter RAM used (out of a possible 1024 ) = 328
The DSP is hooked up to a STM32 micro vis a SPI bus. On power up or reset, the micro resets the DSP, waits 25ms for the PLL to stabilize, activates SPI slave control (toggles the CS line three times) then writes the program & parameter to the DSP (as per function default_download_DSP() from the code generated by Sigma Studio).
In order to extract audio signal levels from the DSP, the micro performs a read every 100ms of all the DSP readback blocks. Each readback block reads the value from a MS Signal Envelope with TC = Decay = 100dB/s. These read values are then converted to dB and fed to a VU-meter style display. The final effect is quite satisfactory and working well with the chosen TC and decay values of the MS Signal Envelopes.
However, I have come across two issues, one of which is a showstopper.
After a reset of micro with no audio signal present on any input (i.e. all power supply & audio voltage levels are stable) the micro then resets the DSP, goes through the DSP startup procedure described above and proceeds every 100ms to read all readback blocks.
After every reset, some of the MS Signal Envelope / Readback blocks "misbehave", returning a random value that decays to zero over a period of time. This period ranges from ~200ms to ~3 seconds after reset. The remaining blocks return zero (as expected since there is no audio signal present).
Once the affected block's value had decayed to zero, normal operation is seen where the readback value follows any applied input signal.
It will not always be the same MS Signal Envelope / Readback block that is affected. It appears to be a random infliction with no discernable pattern. No two affected blocks will have the same initial value or decay time. Once the affected blocks have decayed to zero, the "misbehaviour" is not seen again; it only occurs after the DSP reset / startup procedure.
One interesting point to note is that when I remove some of the filters in the DSP and thus reduce the number of instructions (MIPS), this "misbehaviour" is then rarely seen. When seen, the initial value read is much smaller & the decay time very small (< 300ms).
Issue #2 (showstopper):
Occasionally, after reset, one of the MS Signal Envelope / Readback blocks "lock up", permanently returning a value of 0xFFFFFF. The value does not change over time. Only another reset will return the block to normal operation.
Again, it will not always be the same MS Signal Envelope / Readback block that is affected. It appears to be a random infliction with no discernable pattern. This issue is rare, only seen in one out of five resets.
Since the issue does not resolve over time (as with issue #1), this is a major problem with the VU meter display showing full scale when no signal is present.
Hoping that someone can shed some light on what is happening & how I can resolve it.