Alternative Clock Source for PDM Interface

[jjaime2]

I am working with the nRF52840 DK and was looking for ways to use an alternative clock source for the PDM interface's master clock generator. For instance, would it be possible to use one of the 16MHz timers as opposed to whatever HFCLK is set to? I ask this because I am interested in syncing the PDM clocks of multiple nRF52840s and have begun implementing wireless timer synchronization which makes use of timers to synchronize a GPIO pin toggling. Alternatively, would it be possible to synchronize the 32MHz peripheral clock and use that as a clock source for the PDM interface? The goal is to have 2 wireless microphone streams and have them start at the same time, as well as to prevent the PDM clocks used for these streams from drifting apart.

[haakonsh]

For instance, would it be possible to use one of the 16MHz timers as opposed to whatever HFCLK is set to?

 No, the 32MHz clock is the only source available.  

Alternatively, would it be possible to synchronize the 32MHz peripheral clock and use that as a clock source for the PDM interface?

he goal is to have 2 wireless microphone streams and have them start at the same time, as well as to prevent the PDM clocks used for these streams from drifting apart.

You can use the TIMERs to start-stop transfers on a regular basis in order to adjust for drift over time. 
You can also trim the PDMCLKCTRL, this should be the first option as you can reduce drift by quite a lot during your production test. 
A more advanced synchronization can involve trimming PDMCLKCTRL on-the-fly based on data from your wireless synchronization scheme. 

[jjaime2]

Could you elaborate on trimming the PDMCLKCTRL register? Currently, we have both devices set to the same frequency, would we need to constantly be finely adjusting this register to achieve a nominal frequency, and does the register provide that level of granularity? I believe I read that the register only performs integer division of the HFCLK so I am worried that fine adjustments won't be possible.

For clarity, we should be able to change the register while the PDM clock is active correct? We cannot stop the PDM stream because our application is in telephony.

Finally, would it be possible to write a custom PDM driver using the 16MHz timers instead?

[haakonsh]

jjaime2 said:

Could you elaborate on trimming the PDMCLKCTRL register? Currently, we have both devices set to the same frequency, would we need to constantly be finely adjusting this register to achieve a nominal frequency, and does the register provide that level of granularity? I believe I read that the register only performs integer division of the HFCLK so I am worried that fine adjustments won't be possible.

 It's probably integer divisions, so the resolution won't be that great. 
 

jjaime2 said:

For clarity, we should be able to change the register while the PDM clock is active correct?

 I'll have to ask the devs.  

jjaime2 said:

Finally, would it be possible to write a custom PDM driver using the 16MHz timers instead?

 No, the limitation is in HW, the PDM peripheral is tied to the PCLK32M and the 16MHz TIMERs are derived from the same source as PCLK32M. 

You can use higher accuracy 32MHz crystals, or you can check out our new nRF5340 that has a dedicated audio PLL clock source. See Audio oscillator and PDM — Pulse density modulation interface.

[mkimhj]

Hi,

I'd like to expand on this reply.

Why is writing a custom PDM driver not possible? Is it feasible at all to have an entirely new driver that outputs a PDM clock from the time synced clock? From there, anytime the clock fires, can we not sample the PDM_DATA line manually, or put it into a DMA. After 64 clock cycles pass, we then convert the 64 bits into a 16bit pcm data sample. Is the issue here that we would be starving the CPU?

[haakonsh]

You're free to bit-bang a PDM interface, but you won't be able to use any of the PDM Peripheral's HW blocks as it is controlled by an internal state-machine that runs independently from the CPU.