X-NUCLEO-CCA02M2 PDM-over-SPI capture issue on STM32MP257F-EV1 - discontinuous clocking suspected
Subject: X-NUCLEO-CCA02M2 PDM-over-SPI capture issue on STM32MP257F-EV1 - discontinuous clocking suspected
Hello ST Support Team,
I'm working with an X-NUCLEO-CCA02M2 dual PDM microphone expansion board interfaced to an STM32MP257F-EV1 evaluation board, and I'm running into a data-quality issue I'd appreciate your guidance on.
Setup:
- X-NUCLEO-CCA02M2 board, using onboard microphone M2 (MIC_PDM34_OB), routed via SB10 solder bridge to CN10 pin 15
- Connected to the STM32MP257F-EV1's SPI8 peripheral in Linux userspace via /dev/spidev, MISO on mikroBUS pin 5 (PZ1), clock supplied from SPI8's own SCK (mikroBUS pin 4, PZ2) to CN10 pin 29 (MIC_CLK_NUCLEO)
- Power from CN6 pin 3 (3.3V), GND from CN6 pins 6/7
- Capturing via repeated SPI read calls (spidev, bufsiz increased to 65536, Mode 0)
Issue:
Short, isolated SPI captures (around 2000 bytes at a time, with pauses between reads) show clearly responsive behavior - bit density in the captured stream increases noticeably when speaking near the microphone, and this is reproducible across multiple separate test runs. This confirms the microphone and SPI wiring are fundamentally working.
However, when I capture continuously across multiple sequential chunks (to build up a longer audio recording), the result is isolated spikes of activity separated by long silent gaps, rather than continuous, intelligible audio data.
Diagnostic steps taken:
- Tied MISO to GND and separately to VCC as sanity checks - captures read a stable 0% and 100% bit density respectively, confirming our capture code itself is accurate
- With MISO completely disconnected from the microphone board, the same cyclical rise-and-fall pattern still appears in continuous captures - suggesting this pattern is an artifact of our capture timing, not genuine microphone data
- Tried various mitigations: basic decimation, a moving-average filter, larger read chunk sizes, discarding the first bytes of each chunk, randomized inter-read delays, and all four SPI clock modes (Mode 0 performed best)
Given the short-burst captures work correctly but continuous multi-chunk captures don't, my working hypothesis is that gaps between successive SPI read() calls (as the userspace driver re-arms each transfer) may be interrupting the PDM bitstream's timing in a way the microphone or our decoder can't tolerate - essentially a discontinuous-clocking problem.
Could you advise:
1. Whether continuous, gap-free SPI clocking is required for proper PDM decoding with this microphone, and if so, what tolerance (if any) exists for brief clock gaps between transfers
2. Whether there's a recommended approach for continuous PDM-over-SPI capture on STM32MP2-series parts specifically - e.g., a DMA-based or circular-buffer capture method that avoids gaps between reads
3. Any reference application notes or example code for continuous PDM microphone capture with the X-NUCLEO-CCA02M2 that might address this
Happy to provide additional logs, an oscilloscope capture of the SPI lines, or any other diagnostic information that would help.
Thank you for your time.
Best regards
