I am sending a chirp that sweeps form 20Hz to 500Hz to an audio codec, CS42L52, connected to an MCU, STM32F405, and I am receiving a "wavy" amplitude output. There is no processing on the MCU, I pass the signal straight from the DMA in to the DMA out. The DMA services the I2S lines. If I change the time that the chirp takes to get from 20 to 500 Hz, the amplitude wave changes its frequency.

This picture shows the chirp with a 10 second duration on top and 5 second duration on bottom, and shows that the amplitude frequency is twice as fast in the 5 second chirp vs the 10 second chirp.


Looking at the codec block diagram, it shows that I can bypass the MCU in two different spots. The first being right after the PGA inputs and the next after gain adjust and ALC.


Both of these pass to the codec's DSP and then out to the codec's DAC according to this block diagram.


When I pass the signal through either of these lines, skipping the MCU, the output has a constant amplitude as it should. The input signal is clean, no "wavy" amplitude. If I put one frequency through the device, no chirp, the amplitude stays constant. I have played with a lot of the settings on the codec and can't seem to find any that affect the amplitude wave. Maybe I am overlooking a setting? This almost makes me think it is an MCU problem, but I am not manipulating the signal at all on the MCU. Is it a problem that the DMA stores it as an unsigned integer? What could be the problem?

My sampling frequency is set at 48 kHz, but I measure it at 48.5 kHz, could this affect it?


1 Answer 1


These could be ripples in the frequency response of an (ill-configured) anti-aliasing filter involved in the acquisition or restitution of the signal. It could be that the code running on your MCU and initializing the codec sends invalid configuration information to the codec; causing the codec to work with filters coefficients defined for a wrong sample rate. One thing worth noting is that the STM32F4 I2S master can only output an MCK at 256x FS. Check that your codec can work at 48kHz with such an MCK frequency.

Another thing I can think of is your software "pass-through" routine on the MCU dropping samples. Depending on the ratio between the block size and the period of the waveform, an amplitude modulation effect could appear.

  • $\begingroup$ I don't see any information about configuring anti-aliasing filters in the codec, would this be something that I cannot configure? The codec does work at 256x Fs and at 48 kHz, but the clock is slightly high, possibly 2% high. I don't believe that I am dropping any samples. I have a ping-pong buffer setup that completes in plenty of time. Also, I do not hear any distortion in the signal, everything sounds great. Could it be anything else? $\endgroup$
    – Rick
    Nov 8, 2014 at 19:42
  • 1
    $\begingroup$ I have fixed the Fs using an external oscillator. It is now 48kHz and it still has the same problem. The codec has an auto configure for the clock which I am using, so I think it should be configured correctly. I have also manually configured it with the same results. $\endgroup$
    – Rick
    Nov 9, 2014 at 2:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.