Assertion during startup when declaring an uart in the device tree

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
  • Hi,

     

    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?

    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

Reply
  • Hi,

     

    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?

    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

Children
  • 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.

  • 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

  • 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).

  • 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

Related