Assertion during startup when declaring an uart in the device tree

RE: Assertion during startup when declaring an uart in the device tree

Håkon Alseth — Tue, 20 May 2025 15:15:36 GMT

Hi,

[quote user="tmaltesen"]

But this does not seem to do the trick. If I remove my previous fix, I am back to the old behaviour. OR maybe it does actually work - doing some prestine builds to verify.

[/quote]

I would recommend that you delete your build directory and create an new build instead of doing pristine.

If you still have issues, please share the build/my_app/mcuboot/zephyr/zephyr.dts and .config.

Kind regards,

Håkon

RE: Assertion during startup when declaring an uart in the device tree

Thomas — Tue, 20 May 2025 12:40:22 GMT

Not much saved in mcuboot, but thats fine.

FLASH saved 156 byte RAM saved 24 bytes.

But this does not seem to do the trick. If I remove my previous fix, I am back to the old behaviour. OR maybe it does actually work - doing some prestine builds to verify.

But I have devices in the field, will that not be a problem because they do not get mcuboot updated (or?)

RE: Assertion during startup when declaring an uart in the device tree

Håkon Alseth — Mon, 12 May 2025 08:24:54 GMT

Hi,

Thank you for posting the workaround on your side. I will report this internally.

This explains why I had issues reproducing it, as I do not have anything connected to those specific uart lines on my side.

What happens is that mcuboot does not do a cleanup of that specific uart instance, and this specific uart instance generates an event while tf-m is executing.

Your fix is valid, but another fix is to disable this instance in mcuboot:

sysbuild/mcuboot/boards/$(BOARD).overlay

for PMI8004:

pmi8004_nrf9151.overlay (Note: lack of ns prefix)

Holding:

&uart2 {
    status = "disabled";
};

This will save you space in the mcuboot image, given that you do not use uart2 for mcuboot-recovery services.

Kind regards,

Håkon

RE: Assertion during startup when declaring an uart in the device tree

Thomas — Thu, 08 May 2025 14:22:34 GMT

Really strange we have replicated the same thing at least 10 times with new project and build. But last time we updated from SDK 3.0.0 to 3.0.1 and we saw a little difference. But I'm quite sure that after correcting Kconfig we had same problem. We have been working in several parallel tracks.

Did you include the board file in the project boards folder. The nrf9151dk_nrf9151_ns.conf?

It was a college of mine that have reproduced it the last few times.

Right now we are runing with a workaround where we have patched SDK files. We have added the following that at least seems to do the trick:

In the file: <sdk>\bootloader\mcuboot\boot\zephyr\nrf_cleanup.c

#if defined(NRF_UARTE_CLEANUP)

static NRF_UARTE_Type *nrf_uarte_to_clean[] = {

#if defined(NRF_UARTE0)

NRF_UARTE0,

#endif

#if defined(NRF_UARTE1)

NRF_UARTE1,

#endif

#if defined(NRF_UARTE2)

NRF_UARTE2,

#endif

#if defined(NRF_UARTE20)

NRF_UARTE20,

#endif

#if defined(NRF_UARTE30)

NRF_UARTE30,

#endif

};

#endif

RE: Assertion during startup when declaring an uart in the device tree

Håkon Alseth — Thu, 08 May 2025 14:05:23 GMT

Hi,

Thank you for the board files. I ran your board, in azure_iot_hub, with pmi8004_nrf9151_ns.conf (basically copied from the other files), checked that the modbus entry exists, and it boots:

*** Booting My Application v2.1.0-dev-ae1ee57f3906 ***
*** Using nRF Connect SDK v3.0.1-9eb5615da66b ***
*** Using Zephyr OS v4.0.99-77f865b8f8d0 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Image version: v0.0.0
�All pins have been configured as non-secure
Booting TF-M v2.1.1-ncs4-1
[Sec Thread] Secure image initializing!
*** Booting nRF Connect SDK v3.0.1-9eb5615da66b ***
*** Using Zephyr OS v4.0.99-77f865b8f8d0 ***
[00:00:00.253,936] <inf> azure_iot_hub_sample: Azure IoT Hub sample started
[00:00:00.253,967] <inf> azure_iot_hub_sample: Bringing network interface up and connecting to the network
[00:00:00.539,031] <inf> azure_iot_hub_sample: Device ID: my-device
[00:00:00.539,062] <inf> azure_iot_hub_sample: Host name: 
+CGEV: EXCE STATUS 0
+CEREG: 2,"8169","014A0302",7
%MDMEV: PRACH CE-LEVEL 0
+CSCON: 1
+CGEV: ME PDN ACT 0
%MDMEV: SEARCH STATUS 2
+CEREG: 1,"8169","014A0302",7,,,"11100000","11100000"
[00:00:04.934,326] <inf> azure_iot_hub_sample: Network connectivity established and IP address assigned
[00:00:04.934,448] <inf> azure_iot_hub_sample: Connected to network
[00:00:04.934,997] <inf> azure_fota: Current firmware version: 0.0.0-dev
[00:00:04.935,028] <inf> azure_iot_hub_sample: Azure IoT Hub library initialized
[00:00:04.935,028] <inf> azure_iot_hub_sample: AZURE_IOT_HUB_EVT_CONNECTING
[00:00:04.935,272] <err> mqtt_helper: getaddrinfo() failed, error -2
[00:00:04.935,302] <err> azure_iot_hub: mqtt_helper_connect failed, error: 2
[00:00:04.935,333] <inf> azure_iot_hub_sample: Connection request sent to IoT Hub
+CGEV: IPV6 0

I also checked the compiled zephyr.dts, and the uart2 entry is as you describe it.

Could you try to delete your build folder (ie. not pristine build) and regenerate the build in vscode to see if this helps the scenario?

Kind regards,

Håkon

RE: Assertion during startup when declaring an uart in the device tree

Thomas — Thu, 08 May 2025 09:20:21 GMT

devzone.nordicsemi.com/.../PMI8004.zip

I have attached my board file.

Project itself is the Azure sample with just the two CONFIG modifications that makes it buildable (maybe only one is needed, but I used two).

RE: Assertion during startup when declaring an uart in the device tree

Håkon Alseth — Thu, 08 May 2025 08:53:56 GMT

Hi,

Could you share the full modifications that you used?

Did you try turning off logging in TFM to see if this helped?

Kind regards,

Håkon

RE: Assertion during startup when declaring an uart in the device tree

Thomas — Wed, 07 May 2025 12:49:54 GMT

I have not set anything up for TFM. I'm using out of the box sample.

This can be recreated by using the sample and just modifying a DK board DTS to use uart2.

RE: Assertion during startup when declaring an uart in the device tree

Håkon Alseth — Wed, 07 May 2025 11:57:21 GMT

Hi,

[quote user=""]Best guess it is related to TF-M, but I have now used a week without figuring out what need to be modified. I guess a single CONFIG ting will fix it but which?[/quote]

By default, TFM uses uart1 for logging, and this can be silenced/disabled using:

CONFIG_TFM_SECURE_UART=n
CONFIG_TFM_LOG_LEVEL_SILENCE=y

Have you setup your custom board with a different uart for tfm, and this crashes with either the pins or the instance (uart2) ?

Do you still see an assert after disabling logging in tfm?

Kind regards,

Håkon