cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F4 I2S clock configuration for stereo PDM

sully
Associate II

Hi guys,

I have an STM32F412 discovery board and am attempting to find the best solution for connecting 8xPDM microphones in 4xStereo pairs and writing the resulting WAV to USB.

The method I'm currently attempting is:

  • Use 4xI2S peripherals, each with 2xPDM mics
  • Each I2S peripheral samples at double the rate (i want 16Khz so I use 32khz)
  • I2Sx_CK goes to TIMx_CHxIN, which halves the clock and TIMx_CHxOUT goes to the PDM mics
  • I perform manual de-interleaving of the bits and then use PDM2PCM library

My problem is that I can get a mono mic working no problems, but as soon as I try a stereo PDM configuration I get garbage (even if only 1 mic is connected) and after trying many other things I'm starting to suspect the problem is with my clock/timer setup.

After reviewing AN5027 (interfacing with PDM mics), I noticed it says for stereo I must use PLLR for the I2S clock source, not PLLI2SR (see table below).

0690X000006CDC5QAO.jpg

I'm trying to follow the recommendations in the table for 16Khz Stereo, but I can't work out how to set this in a way that doesn't cause havoc with all the other peripherals and MCU?

I've got my attempt at clock setup, using PLLR instead of PLLI2SR for "I2S1 Clock Mux".

0690X000006CDCKQA4.jpg

Does anyone have advice on how to interpret this requirement and setup my clock config to suit stereo PDM, USB and a good (>80Mhz hopefully) MCU supply clock?

Thanks

2 REPLIES 2

16kHz? What's your oversampling, i.e. what's the clock frequency?

In the following I assume the value 64 from the given appnote. Non-power-of-2 oversampling is of course possible, but I wouldn't expect it to be supported by a ready-made library, and I don't think you want to develop your own downsampler/filter, especially with such an unusual property (i.e. the non-power-of-2 factor).

For those who did not read the given appnote: the trick described there is that the I2S clock is divided by 2 in a timer, and then the result is fed to the L/R inputs of the mics, so that one mic outputs its current bit (and I2S samples it) in the even bit slots, and the other mic does the same in the odd bit slots.

The basic problem with using two PLLs is, that if you source the clock from one PLL (through I2S) and then resample it (in the timer) by derivative frequency of the other PLL, you will get jitter which will have frequency content given among other things by cross-products ("beats") between the two PLLs. The jitter will result in unwanted frequency content in the audio input, and given the PLLs themselves are jittery, their cross-products may well fall into the audible region.

In this particular mcu, if you don't use the PLLI2S for I2S, you can use it to generate the 48MHz for USB; it's trivial from the 8MHz crystal (divide by 8, multiply by an integer multiple of 48 so that result fits into VCO range, divide by the same integer to drop to 48MHz, done).

With the given constraints of PLL/VCO, there's no way to achieve a perfect 16kHz x 64 = 2.048MHz mic clock (i.e. integer multiple of 2x2.048MHz (PLL divides its input by 2x(2xI2S_DIV+ODD) to the bitclock if MCO is not used) as R output of the PLL going to I2S) while having >80MHz system clock. But why don't you use a more suitable crystal, e.g. the fairly common 12.288MHz (or 24.576MHz = 2 x 12.288MHz)?

12.288MHz (HSE) / 8 (PLLM) = 1.536MHz (PLL input freq)

1.536MHz x 128(PLLN) = 196.608MHz (VCO output freq)

196.608MHz / 2 (PLLP and PLLR) = 98.304MHz (both to SYSCLK mux and to I2S)

98.304MHz / 2 / 24 (I2S_DIV) = 2.048MHz bitclock

and for USB

12.288MHz (HSE) / 8 (PLLI2SM) = 1.536MHz (PLLI2S input freq)

1.536MHz x 125 (PLLI2SN) = 192MHz (PLLI2S VCO output freq)

192 / 4 (PLLI2SQ) = 48MHz (to USB)

Using the same divider for P and R would also remove any doubts about possible audible artefacts even if the timer's clock comes from the same PLL VCO, but is divided differently than the I2S clock.

JW

There are also better ways to achieve the div/2 clock for the mic's LR signal, removing the need for constraining the clock scheme, allowing to use the PLLI2S for the audio/mics independently from the rest of the chip.

One, very straighforward, is to use an external chip to do the division, e.g. a 74x74.

Other, with no external chip, is to use one of the I2S as a clock generator, in MasterTx mode, outputting a 0x5555 data pattern continuously - the data output then will represent the div/2 i.e. the LR signal. Other I2S then in SlaveRx mode can be used as the receivers. If there is an I2Sext module, then even the bitclock signal does not need to be connected externally, sparing down one physical pin.

JW