Unstable ACLK

RE: Unstable ACLK

Elfving — Tue, 24 Feb 2026 15:19:44 GMT

Hi again, and thanks for the patience.

[quote user="RafaelV"]

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.

[/quote]

I am not sure if I understand - what is the deviation you are seeing if not duty cycle?

I would also recommend that you check this with a frequency analyzer, even though 4GSa/s does sound okay.

[quote user="RafaelV"]

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.

[/quote]

Understood. Though this depends on the HFXO, you can always choose a crystal with better properties if you prefer. I wouldn't say that we've found out that there is a 1500ppm jitter here, but even if it were that, shouldn't lead to drift.

[quote user="RafaelV"]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. [/quote]

This might help if you want more of a technical understanding.

Regards,

Elfving

RE: Unstable ACLK

RafaelV — Wed, 18 Feb 2026 12:46:33 GMT

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

RE: Unstable ACLK

Elfving — Fri, 13 Feb 2026 14:32:58 GMT

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

RE: Unstable ACLK

RafaelV — Thu, 12 Feb 2026 16:56:54 GMT

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

RE: Unstable ACLK

Elfving — Mon, 09 Feb 2026 14:43:04 GMT

I do not think your code starts up the HFXO.

Try adding this function and run it.

Regards,

Elfving

RE: Unstable ACLK

RafaelV — Fri, 06 Feb 2026 15:47:30 GMT

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

RE: Unstable ACLK

Elfving — Fri, 06 Feb 2026 13:57:39 GMT

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

RE: Unstable ACLK

RafaelV — Fri, 06 Feb 2026 13:52:49 GMT

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?

RE: Unstable ACLK

Elfving — Fri, 06 Feb 2026 13:47:34 GMT

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

RE: Unstable ACLK

Elfving — Mon, 02 Feb 2026 15:28:59 GMT

Hi Rafeal,

I'll have to get back to you on this later this week.

Regards,

Elfving

RE: Unstable ACLK

Turbo J — Fri, 30 Jan 2026 19:55:02 GMT

Try 64kHz with 32 bit samples. The I²S peripherial is limited to max 96kHz LR clock, no idea if that could cause problems for MCK.