i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

lawrencecaroll — Wed, 16 Jul 2025 11:26:38 GMT

thanks fot sharing!]

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

ducklife12 — Fri, 19 Jul 2024 03:33:33 GMT

I read this post and, if possible, I'd want to give some fascinating topics or suggestions to you. Perhaps you could refer to this topic in your next article. I'd like to learn more about it! Thanks! vex game

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

AHaug — Wed, 26 Jun 2024 12:05:41 GMT

Great! Thank you for the update and good luck in your project.

As always, please feel free to open new cases for new questions and queries

Kind regards,
Andreas

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

responsible_duck — Tue, 25 Jun 2024 15:42:52 GMT

Hi thanks for the advice!

Our solution was to duplicate the `.overlay` files from the main app into the `child_image/mcuboot/boards` path. The i2s line now starts normally and we can use it to transfer audio data.

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

AHaug — Tue, 25 Jun 2024 09:03:44 GMT

Hi Ever,

Apologies for the long response time since last you heard from me...

Could you give me an update w.r.t your status? Are you still seeing issues with selecting child images?

Regarding your question: This should be explained in https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/config_and_build/multi_image.html, maybe more specifically the section regarding enabling the child image: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/config_and_build/multi_image.html#defining_and_enabling_a_child_image

[quote user="responsible_duck"]child_imgage[/quote]

Just for sanities sake, if there is a typo in the repository's name, then the build system may not recognize this as a child_image repository and thus may be struggling with finding which child image it should select. If it's named properly then the build system typically does find what it needs based on your build target and configurations in the child_image repository if you have a child image there

Kind regards,
Andreas

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

AHaug — Fri, 14 Jun 2024 14:52:15 GMT

Hi,

Happy to hear that!

I believe that lesson 3 in https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/ should address some neat tips and tricks w.r.t custom boards (I could be wrong), but that is unfortunately all I could manage to find before the weekend. If you could have a look at that/those topics until I look further into this during the start of next week and let me know if this answers your question or not, that would be great

Kind regards,
Andreas

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

responsible_duck — Thu, 13 Jun 2024 14:11:49 GMT

Thanks this is helpful! If we have multiple .dts files or boards in the child_imgage/mcuboot/boards/ folder, how do we choose the board configuration in VS Code? For example, for the main app we can simply select board and add any overlays...

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

AHaug — Thu, 13 Jun 2024 08:30:37 GMT

Hi,

[quote user="responsible_duck"] I think I want mcuboot to just use the same overlay as my main app so that pins do not conflict. Is that possible? If so, how can I do it?[/quote]

Yes, this is correct. You will have to add a child image overlay file for any multi-image build to ensure that all parts uses the same configuration.

To ensure that MCUboot uses the same overlay as the application in NCS, you need to provide overlays for a child image (e.g. MCUboot) using its own overlay file. The build system automatically applies any device tree overlay located in the child_image folder provided you follow the schema (e.g. <project_root>/child_image/mcuboot/boards/nrf52840dk_nrf52840.overlay).

For example, if you have specific configurations for your application, you should put the overlay of your board inside the boards folder. This way, the relevant parameters to build MCUboot correctly to work with the chosen application will be passed automatically to the MCUboot build system so they are in concert with each other.

Also, make sure to set in your parent image conf CONFIG_BOOTLOADER_MCUBOOT=y to signify it will be chain loaded by MCUboot.

For more information regarding multi-image builds, you can refer to the documentation:

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/config_and_build/multi_image.html and https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/device_guides/nrf53/multi_image_nrf5340.html

[quote user="responsible_duck"]This seems to work for our app but I think mcuboot only picks up the common dts configurations and not the custom board overlays? Why is that even though it is built together with the app?[/quote]

There are two options that could cause this, the first is that not all images are not using the same overlay, and the second is that you're building for a board that has a slightly different name than the overlays name.

The current build system chooses devicetree files based on the build targets name, meaning that if you build for for instance "nrf52840dk_nrf52840" it will use the "nrf52840dk_nrf52840.dts" from zephyr/boards as well as any "nrf52840dk_nrf52840.overlay" in your project folder. If your build target is "nrf5248dk_nrf52840_custom", it will look for any overlays that ends with "_custom" in your project folder, meaning that if you have a "nrf52840dk_nrf52840.overlay" will be ignored since it is looking for the overlay ending with "_custom.overlay" (unless you specify this as a Kconfig fragment when building).

To summarize: Your overlays needs to have the same naming convention as your board/build target.

Kind regards,
Andreas

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

responsible_duck — Wed, 12 Jun 2024 14:30:26 GMT

AHaug I think I want mcuboot to just use the same overlay as my main app so that pins do not conflict. Is that possible? If so, how can I do it?

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

responsible_duck — Wed, 12 Jun 2024 06:11:04 GMT

I tried cherrypicking the fix mentioned above (https://github.com/nrfconnect/sdk-mcuboot/pull/303) in my local v2.6.1 sdk but it did not resolve the issue.

So we have a nrf5340_cpuapp_common-pinctrl.dtsi file that we use mainly to build for devkit. This contains a uart definition that seems to reflect the uart configuration you linked:

&pinctrl {
	uart0_default: uart0_default {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 20)>,
				<NRF_PSEL(UART_RTS, 0, 19)>;
		};
		group2 {
			psels = <NRF_PSEL(UART_RX, 0, 22)>,
				<NRF_PSEL(UART_CTS, 0, 21)>;
			bias-pull-up;
		};
	};
}

In our custom board overlay we reconfigure these pins to be i2s:

/delete-node/ &{/pin-controller/uart0_default/group1/};
/delete-node/ &{/pin-controller/uart0_default/group2/};
/delete-node/ &{/pin-controller/uart0_sleep/group1/};

&uart0_default {
    group1 {
        psels = <NRF_PSEL(UART_RX, 0, 9)>, <NRF_PSEL(UART_TX, 0, 11)>;
    };
};

//  Pin configurations for PDM device
&pinctrl {
    pdm0_default_alt: pdm0_default_alt {
        group1 {
            psels = <NRF_PSEL(PDM_CLK, 0, 4)>,
                    <NRF_PSEL(PDM_DIN, 0, 5)>;
        };
    };

    i2s0_default: i2s0_default {
        group1 {
            psels = <NRF_PSEL(I2S_LRCK_M, 0, 20)>,
                    <NRF_PSEL(I2S_SDIN, 0, 21)>,
                    <NRF_PSEL(I2S_SCK_M, 0, 19)>;
        };
    };
}

This seems to work for our app but I think mcuboot only picks up the common dts configurations and not the custom board overlays? Why is that even though it is built together with the app?

Any other suggestions on why i2s is not functioning after entering app from serial recovery mode?

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

AHaug — Fri, 07 Jun 2024 12:38:13 GMT

[quote user="responsible_duck"]So I guess we would use the bootloader's default pinout?[/quote]

That might resolve the issue, but it would require verification through testing

[quote user="responsible_duck"]Do these correspond with the lines used for UARTE?[/quote]

Atleast for the DK it is set up as explained in https://docs.nordicsemi.com/bundle/ug_nrf5340_dk/page/UG/dk/vir_com_port.html#ariaid-title1

But since you're using a custom board it will depend your board files

Kind regards,
Andreas

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

responsible_duck — Fri, 07 Jun 2024 12:16:47 GMT

We use P0.19-21 for the i2s lines in our app but don't have a specified overlay for our bootloader (besides button to enter serial recovery). So I guess we would use the bootloader's default pinout? Do these correspond with the lines used for UARTE?

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

AHaug — Fri, 07 Jun 2024 12:02:52 GMT

You can always cherrypick the suggested fix into your fork of the main ncs branch: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/dev_model_and_contributions.html contains resources for how to manage your own fork and add cherrypick fixes to it.

I see that the PR is not merged into main, but I suspect it will happen soon based on the comment from yesterday.

In addition, I'm a bit uncertain if this PR fixes the issue, but your symptoms (and the fix) suggests it may do. If your I2s uses the same pins as your UART1 does, then is should be reinitialized by the I2s driver when your app start. Could you check and verify if you're using a different pinout when you're in bootloader than when you're in the app?

Kind regards,
Andreas

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

responsible_duck — Fri, 07 Jun 2024 11:48:56 GMT

Hi,

Thanks for this update AHaug ! Unfortunately this is blocking us could you instruct me as to how to point my project's MCUBoot to a branch or local version so I can use this fix in the mean time?

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

AHaug — Fri, 07 Jun 2024 08:41:06 GMT

Hi again,

It looks to be related to this PR: https://github.com/nrfconnect/sdk-mcuboot/pull/303

I will ask around internally for status regarding this issue.

Kind regards,
Andreas

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

AHaug — Fri, 07 Jun 2024 08:31:20 GMT

Hi,

Glad you were able to resolve this. I were about to reach out to you regarding setting the serial config to n based on some input from my colleagues but it got lost when I were trying to find the reason for why this would be the fix.

From what I were able to uncover after discussing with my colleagues it seems to be caused by something in the cleanup after booting causing this configuration to make it so that some GPIOs still are in use. I will see if I can find more information regarding this or if it has been patched in the soon-to-be-released V2.7.0, but for now this is alteast whats causing it.

Kind regards,
Andreas

RE: i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

responsible_duck — Thu, 06 Jun 2024 18:20:04 GMT

We narrowed it down to serial recovery being enabled:

`CONFIG_MCUBOOT_SERIAL=y`

With MCUBOOT enabled and `CONFIG_MCUBOOT_SERIAL=n` in the `child_image/mcuboot.conf`, our audio pipeline via i2s works fine. However, we need serial recovery mode enabled.

Any insight as to why this would cause i2s to fail?