PDM on 5430 at 3.072MHz random glitches in the stream

Hi,

we have created a new product prototype where audio streaming is the functionality. 2 different HW revisions were so far built, the software originally is built to use a PDM to I2S converter chip, but now we had a chance to investigate the direct recording from the PDM microphones. The format we are using is 48Khz sampling 16bit stereo. This is working perfectly on I2S. However we have noticed weird behavior on the direct PDM recording. 

We managed to create the code to use the microphones, the limitations be:

PDM clock is at 3.072 MHz (as 64X @ 48K) and ACLK clock source at 12.288 MHz. This yields the proper sampling speed. However it seems that the rising edge of the clock is glitchy at random intervals (we can't identify whether this  means 0 samples or some other bit errors, the glitch repeat at around 100ms intervals sounds like static clicking with varied amplitude). We have tested 3 boards and swapped the microphones from left to right to check that it is not the routing on the pcb or the microphones. Glitch stayed always on the rising clock edge. We even tried different IO voltages to rule that out as well 1.8V and 2.3V were tried.

Interestingly the falling edge sampling of the clock works perfectly. (we have muted the other channel to see).

What worked but not usable for us:

- change PDM clock source to 32MHz but this yields sampling rate of 50kHz
- change sampling rate to 24kHz -> this yielded 1.536MHz PDM clock and that ran again fine with the 12.288MHz ACLK source. 

So it seems that the glitch exists only on that one specific frequency (that we need of course). Our codec only allows 48/24/16/12/8 kHz sampling, so we can't try the 44.1kHz related frequencies.

Is there any known issues around this ACLK being 12.288MHz, and PDM clock at 3.072 MHz? Why does it only affect the rising clock edge? Is there anything we can do to make it work, or our best option is to go with the working speed of 24kHz audio sampling and 1.536MHz PDM clock?

Thank you 

Levente

Parents
  • Ohh one more thing, we have changed the PDM to I2S converter to output the same 3.072MHz (it was default to 32X), and the microphone streams over I2S still worked perfectly.

    Also we have tested grounding the PDM data pin while it was running and that caused silence on both channels no glitches heard.

    And we have changed the clock IO driving strength as well, on the scope the clock and data both looked pristine, very fast rising and falling edges on both.

  • Hi,

    I have asked internally and will get back to you as soon as I get a response.

    Best Regards,

    Priyanka

  • Hi,

    Could you provide the following details?

    1. What is value of PDMCLKCTRL ?
    2. Do you run with HFXO or HFINT when using PDM ? 

    -Priyanka

  • Hi there,

    1. this is a print from our app:
    ====== req_freq: 3072000, clk_factor: 233016 act_freq: 3072000
    ====== pdm_cfg->io.min_pdm_clk_freq: 1000000, pdm_cfg->io.max_pdm_clk_freq: 4000000
    !!!!!  PDMCLKCTRL=0x38e38000  = 954433536

    And we have found this in the nrfx driver code:
    /* As specified in the nRF5340 PS:
    *
    * PDMCLKCTRL = 4096 * floor(f_pdm * 1048576 /
    *                           (f_source + f_pdm / 2))
    * f_actual = f_source / floor(1048576 * 4096 / PDMCLKCTRL)
    */

    According to this there is no rounding because the divider is integer.

    2. We are running HFXO, but isn't only HFCLK and ACLK are the actual options to select from the mux for fsource for PDM? We are experiencing the problem only using ACLK.

    My understanding is that ACLK is generated through this (this is the only case that can generate exact 48kHz):
    32M xtal -> HFXO -> HFCLKAUDIO (probably fractional PLL) -> ACLK

    and HFCLK in HFXO case:
    32M xtal -> HFXO -> HFCLK128M -> PCLK32M (this is used as HFCLK)

    and HFCLK in HFINT case - with probably higher jitter and worse accuracy:
    HFINT 128Mhz int. osc. -> HFCLK128M -> PCLK32M

Reply
  • Hi there,

    1. this is a print from our app:
    ====== req_freq: 3072000, clk_factor: 233016 act_freq: 3072000
    ====== pdm_cfg->io.min_pdm_clk_freq: 1000000, pdm_cfg->io.max_pdm_clk_freq: 4000000
    !!!!!  PDMCLKCTRL=0x38e38000  = 954433536

    And we have found this in the nrfx driver code:
    /* As specified in the nRF5340 PS:
    *
    * PDMCLKCTRL = 4096 * floor(f_pdm * 1048576 /
    *                           (f_source + f_pdm / 2))
    * f_actual = f_source / floor(1048576 * 4096 / PDMCLKCTRL)
    */

    According to this there is no rounding because the divider is integer.

    2. We are running HFXO, but isn't only HFCLK and ACLK are the actual options to select from the mux for fsource for PDM? We are experiencing the problem only using ACLK.

    My understanding is that ACLK is generated through this (this is the only case that can generate exact 48kHz):
    32M xtal -> HFXO -> HFCLKAUDIO (probably fractional PLL) -> ACLK

    and HFCLK in HFXO case:
    32M xtal -> HFXO -> HFCLK128M -> PCLK32M (this is used as HFCLK)

    and HFCLK in HFINT case - with probably higher jitter and worse accuracy:
    HFINT 128Mhz int. osc. -> HFCLK128M -> PCLK32M

Children
No Data
Related