Problem bringing up custom board with custom board file

[Thomas]

On a new board based on nRF9160 I am having trouble figuring out how to bring up the board.

I am using Azure IoT hub and can successfully build an application that can connect using the nRF9160DK_NRF9160 Non Secure board files. This is working both on the DK board and on my custom hardware board.

I have copied the nRF9160DK_NRF9160 board to my own board and renamed files and definitions to match my own board.

I can see that when using the DK board package I get a nrf9160dk_nrf9160_ns.conf file with some configuration that I do not find I my board files. I have copied these definitions into my prj.conf file.

When debugging my board using my custom board files (NS) I get this output on J-Link RTT:

00> *** Booting nRF Connect SDK v3.5.99-ncs1 ***
00> I: Starting bootloader
00> I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
00> I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
00> I: Boot source: none
00> I: Image index: 0, Swap type: none
00> I: Bootloader chainload address offset: 0x10000
00> I: Jumping to the first image slot

But when using the board definition for nRF9160DK_NRF9160 Non Secure I get this:

00> *** Booting nRF Connect SDK v3.5.99-ncs1 ***
00> [00:00:16.895,935] <inf> azure_iot_hub_sample: Azure IoT Hub sample started
00> [00:00:16.895,965] <inf> azure_iot_hub_sample: Bringing network interface up and connecting to the network
00> [00:00:17.124,908] <inf> nrf_modem_lib_trace: Trace thread ready

.... connecting and running.

What am I missing for my own board definition. I am working in the same project file with just the above two build definitions...

[Thomas]

The initial problem was caused by the following lines being removed from the DTS file.

    chosen {

        zephyr,console = &uart0;

        zephyr,shell-uart = &uart0;

        zephyr,uart-mcumgr = &uart0;

    };

I need a uart for modbus communication and the declaration of the uart continues to cause problems. After reinserting the above I can start the application. As long as I am not trying to use a uart for my application I can connect to Azure.

I have found that uart1 should not be used as it is used internally for TF-M. So I was declaring uart0for use by modbus with the following DTS:

&uart0 {

    status = "okay";

    current-speed = <115200>;

    pinctrl-0 = <&uart0_default>;

    pinctrl-1 = <&uart0_sleep>;

    pinctrl-names = "default", "sleep";

    modbus0 {

        compatible = "zephyr,modbus-serial";

        status = "okay";

        de-gpios = < &gpio0 8 GPIO_ACTIVE_HIGH>;

    };      

};

In an application that is not connecting using modem this is an OK declaration, and the modbus is working.

But when building an application that also uses modem, I get into trouble. Declaring my application uart to use uart 2 or 3 does work either.

When keeping the "chosen" section above and starting the uart0 using modbus the application stops. Propably caused by a conflict.

How can I use an uart for my application modbus in an application that also uses the modem function?

[Sigurd Hellesvik]

Thomas said:

I have found that uart1 should not be used as it is used internally for TF-M. So I was declaring uart0for use by modbus with the following DTS:

You can turn of TF-M logging with CONFIG_TFM_LOG_LEVEL_SILENCE. Then TF-M will no longer use any UART.

Thomas said:

But when building an application that also uses modem, I get into trouble.

It is odd that UART communication and modem functionality crashes.
Let us debug that.

Do you do anything from UART callbacks? It is usually a good idea to not do a lot in interrupt context, as this may mess up timing requirements from other parts of the system, such  as the modem.

How do you mean that you get trouble using modem and modbus at the same time? Any  specific errors?

[Thomas]

Any help is greaty appreciated. I am so much in trouble with this project...:-(

[Thomas]

In current testing I am ending up in an assertion in tfm_hal_platform_common_init that is calling stdio_init().

Event though I was just thinking that I would not do anything with uart1 (that was supposed to be used by TFM), it seems to have influence. So I will try the suggested CONFIG_FTM_LOG_LEVE_SILENCE...

[Thomas]

Using the CONFIG_TFM_LOG_LEVEL_SILENCE brings me into an assertion. The following line 76 in uart_deprecated_async.c:

    err = pinctrl_apply_state(PINCTRL_DT_DEV_CONFIG_GET(UART1_NL), PINCTRL_STATE_DEFAULT);

    __ASSERT_NO_MSG(err == 0);

It is being called from nrf_modem_lib_trace_init().

[Sigurd Hellesvik]

Ah, looks like modem trace uses UART1.
You could try to disable it if not not needed usingCONFIG_NRF_MODEM_LIB_TRACE.

From Enabling tracing in the application:
"

By default, the nRF Connect SDK’s modem library uses the UART1 peripheral for trace output. This means that you cannot use UART1 for other purposes in your application. If this does not work for your application, you must update the configuration and code of the modem library to use a different UART peripheral for trace output.

"

[Thomas]

It is fine for me not to use uart1. I have kept the following in the device tree:

/* Disable UART1, because it is used by default in TF-M */

&uart1 {

    status = "disabled";

};

In my prj.conf file I have 

CONFIG_TFM_LOG_LEVEL_SILENCE=y

 

Now I am trying with CONFIG_NRF_MODEM_LIB_TRACE=n, I found this in the source code following the call stack.