Unstable ACLK

[RafaelV]

Greetings,

We want to use the MCK of the I2S module as a clock output for an external device. For that, we need a freuqency of around 4,096MHz. 
ACLK originates from the 32MHz HFXO, and can be set to 12.288MHz (nrf5340_PS 4.11.1.3 Audio oscillator). 
The master clock generator can now divide ACLK by 3 to arrive at 4,096MHz. 

Devicetree overlay:

i2s_rx: &i2s0 {
	status = "okay";
	clock-source = "ACLK";
	pinctrl-0 = <&i2s0_default_alt>;
	pinctrl-names = "default";
};

&clock {
    hfclkaudio-frequency = <12288000>;
};

Using the Zephyr API, the I2S registers can not be configured directly, but it works with a small workaround: 

/* --- I2S Parameter --- */
#define SAMPLE_RATE_HZ     128000u
#define WORD_SIZE_BITS     16u
#define CHANNELS           2u

With this, I set the bit-clock to 4,096MHz. MCK should be the same. 

Now, measuring MCK (or SCK) with the oscilloscope shows, that we get an unstable frequency between 4,125MHz and 4,135MHz. 
The main issue for us is not that the frequency is slightly off, but that it appears to be unstable.

I wonder how that can be. The quarz frequency should be reliable, and the Master clock generator just divides the frequency by 3. 
So I would suspect the generation of ACLK to be unstable. 

How exactly is ACLK created? Or do you have any idea what could cause this behavior, or whether there is anything incorrect in my setup?

Thanks a lot :) 

[Elfving]

Thanks for waiting Rafael,

I haven't tested this myself, but getting an unstable frequency does sound weird to me. I've forwarded a question to the relevant R&D team about it as well.

Are you seeing this on a DK or a custom board?

Regards,

Elfving

[RafaelV]

Hey Elfving,

Thank you for forwarding this. I am testing this on the DK. 
And yes, it is also weird to me, as I don't understand where the instability could even come from.

Do you want me to upload the sample project, or make a proof video of the oscilloscope? 

[Elfving]

A sample project would be great! I'll see if I can reproduce it here.

[RafaelV]

I uploaded it to git: https://github.com/F0rtas/nrf5340_I2S_clock_output.git

A few keypoints: 
-I2S is set as slave (Bitclock slave etc)
-I2S is set to RX mode
  -> MCK still runs, but since there is no bitclock, no data is written to the buffer; I2S runs indefinitely
-MCK is set to high drive, and pin 0.12
-clock source is set to ACLK
-hfclkaudio frequency set to 12288000 (12,288MHz / 3 = 4,096MHz)
-Zephyr: 
   -Sample rate: 64MHz
   -word size bits: 32
   -channels: 2
   ->bitclock = 64000MHz * 32 * 2 = 4,096MHz

[Elfving]

I do not think your code starts up the HFXO. 

Try adding this function and run it.

Regards,

Elfving

[RafaelV]

Hey Elfving!

I added the function and it is running now. 

I’ve attached a screenshot from our oscilloscope below. The average frequency is close to 4.096 MHz, which looks fine. However, the measured deviation is about 2.7 kHz, which corresponds to roughly 660 ppm.

Theoretically the quarz should have a lower jitter, right?

Additionally, the duty cycle is not symmetric.

Do you know how ACLK is generated internally? We’re trying to trace where these inaccuracies are introduced.

Most importantly, we need the clock to be stable over time with no long-term drift.

Thanks for all your help :) 

Cheers, Rafael

[Elfving]

Hi,

I think it should be 15ppm, so I agree this looks high. But I didn'tthink it would show itself as jitter. Are you seeing this with eg. a spectrum analyzer as well?

I would expect the jitter to become a bit worse with the i2s division as well. Are you seeing the same with the pure clock signal bypassed or just with this split? 

Regards, and have a good week-end,

Elfving

[RafaelV]

Hey Elfving, 

so, selecting bypass isn't directly possible in Zephyr; I cheated a bit and temporarily set ".enable_bypass = true" in ncs/v3.2.1/modules/hal/nordic/nrfx/drivers/include/nrfx_i2s.h.

The result is a frequency around 12,288MHz, but we can see an even higher deviation of about 19kHz, resulting in around 1500ppm. 

At the same time, the duty cycle seems stable now. I suppose the distorted duty cycle we saw above stems from the MCK generator. 

For us, it is mostly important that the frequency is stable long-term, and doesn't drift. The relatively high jitter mainly makes us cautious about the clock source and its determinism.

hfclkaudio comes from the 32MHz HFXO crystal. The 12,288MHz hfclkaudio can not be achieved through simple division of 32MHz. Do you know, how hfclkaudio is created internally? If we know it to be deterministic, so no delay being introduced, we could exclude an additional drift, that would suffice for us. 

Best regards

Rafael