• State Not Answered
  • Replies 9 replies
  • Subscribers 75 subscribers
  • Views 313 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 344953
Options

Assertion during startup when declaring an uart in the device tree

Thomas

We get the following assertion during startup if we include uart2 in the DTS.

*** 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
Assert:stdio_init,0x00000060e slot

We are creating the problem with a fresh copy of the Azure IoT hub sample on a nRF9151DK.

The Azure IoT hub sample will not link out of the box, there are unresolved externals. So first the following needs to be added to prj.conf

CONFIG_STREAM_FLASH=y
CONFIG_IMG_MANAGER=y

Then a running sample should be OK.

Now if the following is added to the device tree. I copied the nrf9151dk_ns board and renamed according to doc and then added to *_common.dtsi 

&uart2 {
   status = "okay";
   current-speed = <9600>;
   pinctrl-0 = <&uart_rs485_default>;
   pinctrl-1 = <&uart_rs485_sleep>;
   pinctrl-names = "default", "sleep";
   modbus0 {
        compatible = "zephyr,modbus-serial";
        status = "okay";
        de-gpios = < &gpio0 8 GPIO_ACTIVE_HIGH>;
    };      
};
We are uable to run the application after adding an uart.
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?

I am getting quite desperate ;-)

Parents Reply Children
  • 0 in reply to Thomas

    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

  • 0 in reply to Håkon Alseth

    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
  • 0 in reply to Thomas

    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

  • 0 in reply to Håkon Alseth

    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?)

  • 0 in reply to Thomas

    Hi,

     

    Thomas said:

    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.

    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

Related
Terms of service