nrf54L Series I2S MCLK divider?

RE: nrf54L Series I2S MCLK divider?

Elfving — Tue, 17 Feb 2026 14:16:59 GMT

Hi Stefan, I have taken over this case from Hieu for a bit.

[quote user="Stefan Schmidt"]

So I am not going to prepare a pull request.

[/quote]

That is fine. I'll see if I can create a job for this on our backlog here. Thanks for the suggestion!

Regards,

Elfving

RE: nrf54L Series I2S MCLK divider?

Stefan Schmidt — Thu, 12 Feb 2026 21:32:27 GMT

Hi Hieu,

I had a closer look at the driver in nrfx_i2s.c, but I do not understand the logic of how the divider values are calculated. Furthermore I am only using Zephyr, but this driver is most likely also used for baremetal configurations. So I do not understand how an addition to a struct which is used by both approaches would be intitialized in the baremetal world (will the element be set to zero).

So I am not going to prepare a pull request.

Best regards

Stefan

RE: nrf54L Series I2S MCLK divider?

Hieu — Sun, 08 Feb 2026 16:31:18 GMT

Hi Stefan,

My apology for the late follow up.

That is an interesting idea. Would you like to make a pull request for it?
There are some guidelines, but you can just get the implementation out and I can help you adjust things as needed.

If you would like to stop just at sharing the idea, that is of course also welcomed. I will create a task on our backlog.

Best regards,

Hieu

RE: nrf54L Series I2S MCLK divider?

Stefan Schmidt — Tue, 03 Feb 2026 09:16:19 GMT

Mmmh, nrfx_i2s.c is not a Zephyr driver. So the nrfx_i2s_clk_params_t might be extended by a "requested_mck" field which could be filled by the Zephyr driver and kept at/set to 0 for the non-Zepyhr use case

RE: nrf54L Series I2S MCLK divider?

Stefan Schmidt — Tue, 03 Feb 2026 08:43:34 GMT

Hello Hieu,

I am facing a similar issue with a nRF54L15 and a TLV320DAC3100: I also need a MCK which is a lot higher than the BCK.

I do not think that the Zephyr API has to be changed: An extension in the devicetree bindings only for the Nordic SOC would be sufficient. For example, if a MCK clock is set in the devicetree for a Nordic I2S device (e.g. in an overlay) the automatic calculation of the requested mck could be skipped (see function nrfx_i2s_prescalers_calc in nrfx/drivers/src/nrfx_i2s.c)

Best regards

Stefan

RE: nrf54L Series I2S MCLK divider?

Hieu — Fri, 06 Jun 2025 18:39:51 GMT

I am happy to help. I will keep this case opened then. Please feel free to follow up whenever it is convenient for you.

RE: nrf54L Series I2S MCLK divider?

Jasper_Golden — Fri, 06 Jun 2025 08:17:35 GMT

Thank you for the detailed response Hieu. I will need to look into the details you have mentioned. Will do so when I have time for this. The project will need to do without i2s for now unfortunately. Thank you once again.

RE: nrf54L Series I2S MCLK divider?

Hieu — Wed, 04 Jun 2025 22:24:42 GMT

Hi Brian,

My apology. I was optimistic with the driver's capability. While it indeed automatically calculates an I2S configuration based on the i2s_config struct, it doesn't take into account restriction such as the NAU8822's MCK requirement.

I am not certain yet whether I should file an internal ticket about this limitation. It originates from the design of the Zephyr driver, which doesn't take in MCK frequency as an input at all. There is little we can do about that, as changing Zephyr APIs affect all chip vendors, thus isn't something we from Nordic can just unilaterally do.

To proceed, we have two options, which unfortunately both require some level of effort.

1. Use the nrfx driver instead to work with I2S.
I don't have anything to add for option 1. Unfortunately, there isn't a sample, beyond the implementation of the Zephyr I2S driver itself.

2. Hack the Zephyr I2S driver a little.
Considering what I have investigated, this is likely feasible and simpler than option 1.
However, please keep in mind that this is nonetheless modifying existing design, and there can be unexpected consequences.

For this option, we need to look into the current implementation.

The configuration isn't set to the peripheral with the i2s_configure() function. That function only stores the configuration in a structure in the driver. This stored configuration is then set to the peripheral every time i2s_trigger() is called.

Therefore, we need to add a new API to override only the clock related fields of the stored configurations. Here are a few points to note:

The stored configuration is a nrfx_i2s_config_t structure
Two copies of that structure are stored. One for each direction of I2S.
Ref: https://github.com/nrfconnect/sdk-zephyr/blob/v4.0.99-ncs1-1/drivers/i2s/i2s_nrfx.c#L558-L571
The relevant fields are mck_setup and ratio
Ref: https://docs.nordicsemi.com/bundle/nrfx-apis-3.0.2/page/structnrfx_i2s_config_t.html
or in code:
<SDK>\modules\hal\nordic\nrfx\drivers\include\nrfx_i2s.h
<SDK>\modules\hal\nordic\nrfx\hal\nrf_i2s.h
For simplicity, mck_setup can be calculated from ratio and LRCK, referring the original implementation of the driver here:
https://github.com/nrfconnect/sdk-zephyr/blob/v4.0.99-ncs1-1/drivers/i2s/i2s_nrfx.c#L80-L134

My apologies, but I am unable to think of any easier approach.

Hieu

RE: nrf54L Series I2S MCLK divider?

Jasper_Golden — Tue, 03 Jun 2025 18:52:28 GMT

Hi Hieu

Firstly, the 'i2c' referenced in my question is a typo .. indeed it was meant to be i2s.
Your response does not answer my question I'm afraid. Let me explain ..

So my code has the following bit of code .. straight from Nordic Zephyr example. Those that exist all seem to follow the exact same setup.

/* Configure I2S stream */
i2s_cfg.word_size = 16U;
i2s_cfg.channels = 2U;
i2s_cfg.format = I2S_FMT_DATA_FORMAT_I2S;
i2s_cfg.frame_clk_freq = 44100;
i2s_cfg.block_size = BLOCK_SIZE;
i2s_cfg.timeout = 2000;

This code produces an approx. 44100Hz LR Clock a expected. The word size being 16 bits results in a clock of approx. 1,38MHz.
All as expected. But Master Clock pin output still the same frequency as the bit clock pin output.

Regards the response pointing out 'word_size" and "frame_clk_freq"
The WORD Size referenced is 16 bits and frame is 44,1KHz. These variables produce correct bit pattern output.

Your response - "You just need to configure those fields to the appropriate values for your I2S device, and the driver will calculate and configure the ratio under the hood"

Well no .. not for Master Clock. I need a multiple of the 1,38MHz clocked out of the MASTER CLOCK pin. This is what the Master Clock pin is for. What am I missing?

Thank you

Brian

RE: nrf54L Series I2S MCLK divider?

Hieu — Mon, 02 Jun 2025 21:01:19 GMT

Hi Brian,

I think you are using the Zephyr I2S driver together and the i2s_config struct, rather than i2c, right?

The Zephyr I2S driver is several layers of abstraction higher than the registers you are referring from the datasheet. With the Zephyr I2S driver, you will care about the two fields of the i2s_config struct:

- frame_clk_freq

- word_size

You just need to configure those fields to the appropriate values for your I2S device, and the driver will calculate and configure the ratio under the hood.

For reference, the function that does the conversion is: sdk-zephyr/drivers/i2s/i2s_nrfx.c at v4.0.99-ncs1-1 · nrfconnect/sdk-zephyr.

Hieu