I am doing my own project making a basic audio recording device using microcontroller's ADC to get the audio signal from electret microphone and saving data to microSD card. I'm using STM32L476RG Nucleo board and external discrete components. Below is the simplified schematic of the application. enter image description here There is an anti-aliasing filter (440 ohm resistor and 100nF capacitor). Removing it does not change results.

The ADC works based on 8 kHz timer output in DMA mode, so my code based on ADC control is pretty simple: I start the timer and ADC in DMA mode and wait for half complete and full complete interrupts where I simply write ADC data to microSD, then the cycle continues and the audio data is continuous in the time axis.

The problem arises when writing data once the half complete or full complete DMA interrupt occurs. During that time the current increases (that's my hypothesis) and the voltage on the VDDA (ADC source/reference pin) changes. The consequent result - periodical spikes in the audio data exactly at the time of DMA half/full conversion complete interrupt. As of approval I tested changing SPI speed (for microSD communication) which showed that reducing speed had longer spikes and increasing speed had shorter spikes.

So there is the 8 bit audio signal in Audacity. The upper signal is while talking and the lower is being in silence. The audio recording excluding the regular ticking (spikes) is completely fine. enter image description here

I have tried bypass capacitors and filters which did not improve the audio. Also tried using CR2032 cell battery for microSD, but apparently the voltage was too low for microSD to function.

Are there any hardware or software decisions/solutions I can implement that would get rid of this problem? I prefer fixing it in hardware first, but keep using the MCU's ADC.

There is the schematic of Nucleo Board for MCU and VDDA/reference pin powering. enter image description here enter image description here

  • \$\begingroup\$ Whats the layout like? whats the return current path of the SDcard w.r.t. where the ADC is \$\endgroup\$
    – user16222
    Commented Aug 30, 2019 at 18:26
  • \$\begingroup\$ All grounds and voltage supplies of all the components are common and connected to the breadboard's supply and ground lines which are connected to Nucleo's 3v3 and GND pins (schematic provided) \$\endgroup\$
    – Pacukas
    Commented Aug 30, 2019 at 18:32
  • \$\begingroup\$ what about the return current path? does the SDcard have a return path that goes near the ADC? \$\endgroup\$
    – user16222
    Commented Aug 30, 2019 at 18:53
  • 2
    \$\begingroup\$ In my opinion spikes are too big to be caused by the power issues (otherwise device would fail due to power out of spec). Could it be that you simply get data garbage at the end or beginning of the transaction from wrong memory location? In other words issue happens in digital part / logic rather than analog part. \$\endgroup\$
    – Anonymous
    Commented Aug 30, 2019 at 19:34
  • 1
    \$\begingroup\$ I have a similar suspicion to what Anonymous wrote above. Try an experiment: remove R1 & C3 and instead connect a pair of resistors (1k-ish) as a voltage divider between AVdd and GND to that just the divider drivers your ADC-IN (do not put a cap on ADC-IN, but leave your C30 as-is). If your problem is with current spikes then this should show almost no sign of them. If your problem is in the digital domain then this will show them clearly. \$\endgroup\$
    – brhans
    Commented Aug 30, 2019 at 19:46

1 Answer 1


In the comments @Anonymous and @brhans raise an excellent point. In your question you ask how to get rid of this problem, but really you need to understand the problem better first. Is the problem digital or analog? If it's analog, is it due to power supply or other effects? Here are some troubleshooting steps I would recommend:

  1. Examine your data more closely. Per @Anonymous and @brhans, the problem could be somewhere in the data handling. If so, I would expect that these "spikes" contain some pathological values, like 0x00, or 0xFF, or 0x7F, or 0x80. Even if it's not one of these values, any consistent or repeated values should be highly suspect since the real world contains noise. If you see any of these symptoms, then the problem exists in the digital domain.
  2. As @brhans recommends, your next step is to tie ADC_IN to a constant DC value. If the spikes are in the data, then the problem must exist somewhere in the microcontroller. Either noise is getting in on the microcontroller's power supply, or the code is garbling the samples somehow.
  3. If step 2 is clean, then reconnect ADC_IN as normal, but replace the microphone with a short to ground. If the spikes are in the data, then U1 is picking up noise, either from its power supply or other interference.
  4. If the spikes only show up when the microphone is connected, then I'd suspect that the microphone is acting as an antenna and picking up electromagnetic interference.

Possible sources of electromagnetic interference:

  • As you mentioned, the power supply is one potential culprit. You said you've tried decoupling, but in my experience sometimes it takes more decoupling than you might think -- either more capacitance, and/or making sure you have a high-frequency cap in parallel with a low-frequency cap, and/or minimizing the distance between the capacitor and the power pin it's decoupling.
  • Since your problem seems to persist for the duration of the SD card data transfer, I'd also strongly suspect the SD card interface lines. These lines could be switching rapidly and generating radiated or conducted EMI that is getting picked up by another part of the system. To remedy this, I'd recommend some series impedance -- put a 10 ohm resistor on the SCK, MOSI, and MISO lines. The resistor should be located as close to the driver as possible.

Last but not least, as @JohnRB indicates, if this problem is not digital then it will be hugely dependent on the layout, so without more information on your layout we'll all be working blindfolded here.


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.