Thread SDK, nrf52840-dk, app_uart and libuarte

[MarkusK]

Hello,

I'm a bit confused which solution is best and easiest to use a second UART or UARTE in the nrf5 SDK for Thread. Since I want to work with students in a project and prepare exercises, I want to prepare the required project files and configuration files so that it is easier for the students to find their way into them.

As I understand it, the Thread SDK uses UARTE0 for the CLI, so that it is not available except by deactivating the CLI, which I managed to do. However, the CLI is very practical for the students, which is why I would like to leave it activated in the basic configuration.

According to the documentation, the app_uart module uses UART0. The documentation actually always states that the instance is hardcoded and cannot be changed. However, there is the MACRO APP_UART_DRIVER_INSTANCE to set the instance. In the sdk_config.h it is stated that the parameter can only be set to 0. If I set it to 1, a second connected UART-USB bridge works. Setting it to 0, on the other hand, leads to an error. Is it safe to use the app_uart module with the CLI at the same time and to set APP_UART_DRIVER_INSTANCE to 1 or does this lead to problems?

I also created a solution using the library libuarte. I've read that this should be the best solution. I used nrf_libuarte_async here. So that data can also be sent to the nrf52840. However, there are also some questions here and I think that a lot of configuration has to be carried out for a simple uart input and output (e.g. the queue module has to be activated and set in the flash_placement) and the question also arises as to which timer is best is to be used. The softdevice uses RTC0, but we do not use this. RTC1 is used by the app_timer. Normally I would actually use TIMER2 for bytes counting and RTC2 for timeout. However, the RTC2 is apparently used for OpenThread, why this leads to an error:
NRF_LIBUARTE_ASYNC_DEFINE (libuarte, 1, 2, 2, NRF_LIBUARTE_PERIPHERAL_NOT_USED, 255, 3);

RTC0 and TIMER2 works, but use of the softdevice is not possible anymore:
NRF_LIBUARTE_ASYNC_DEFINE (libuarte, 1, 2, 0, NRF_LIBUARTE_PERIPHERAL_NOT_USED, 255, 3);

Whereas using the app_timer does not work:
NRF_LIBUARTE_ASYNC_DEFINE (libuarte, 1, 2, NRF_LIBUARTE_PERIPHERAL_NOT_USED, NRF_LIBUARTE_PERIPHERAL_NOT_USED, 255, 3);
Even if the flag is set in the sdk_config.h:
#define NRF_LIBUARTE_ASYNC_WITH_APP_TIMER 1

There is no compile error. When running in debug mode, I get:
<error> app: ERROR 7 [NRF_ERROR_INVALID_PARAM]

To consume two timers just for the Uart, I find somehow quite a lot. So i am a little bit puzzled. So is it safe to use the app_uart? Is it possible to use libuarte_async with app_timer? Or do i have to use 2 Timer (TIMER2 and TIMER3) for it? Is RTC0 ok, if not using the Saoftdevice?

Regards
Markus

[Edvin]

Hello,

Looking at the libuarte example from SDK\examples\peripheral\libuarte, it looks like it is only using one timer and one RTC by default. It shouldn't matter which one it is, as long as it is not being used by something else. If you do not use the softdevice, both TIMER0 and RTC0 should be available for you to use e.g. for libuarte. 

In the sdk_config.h it is stated that the parameter can only be set to 0. If I set it to 1, a second connected UART-USB bridge works. Setting it to 0, on the other hand, leads to an error. Is it safe to use the app_uart module with the CLI at the same time and to set APP_UART_DRIVER_INSTANCE to 1 or does this lead to problems?

I am not sure I understand? It is hardcoded to 0, but setting it to 0 leads to an error? 

Did you try setting it to 1? Did it cause any errors? Why can't you use the UART1 for what you want to? You say that it is both working and that it leads to an error, so I don't think I understand exactly what you are saying.

Best regards,

Edvin

[MarkusK]

Hello,

of course, i can use TIMER0 and RTC0. But when I want to add the softdevice later, I would have to search again for free resources, especially RTCs are then all used. But I managed to use the app_timer here too:
NRF_LIBUARTE_ASYNC_DEFINE(libuarte, 1, 2, NRF_LIBUARTE_PERIPHERAL_NOT_USED, NRF_LIBUARTE_PERIPHERAL_NOT_USED, 255, 3);

Because of the nrf_libuarte_async_init function i had to use a higher priority for the libuarte_async configuration than the app_timer itself (sdk_config.h:#define APP_TIMER_CONFIG_IRQ_PRIORITY 6):
nrf_libuarte_async_config_t nrf_libuarte_async_config = {
        .tx_pin     = MY_TX_PIN_NUMBER,
        .rx_pin     = MY_RX_PIN_NUMBER,
        .baudrate   = NRF_UARTE_BAUDRATE_115200,
        .parity     = NRF_UARTE_PARITY_EXCLUDED,
        .hwfc       = NRF_UARTE_HWFC_DISABLED,
        .timeout_us = 100,
        .int_prio   = APP_IRQ_PRIORITY_LOW_MID
};



But I still like the solution with the app_uart for projects with the students more. That the instance for the app_uart is hardcoded I found on another discussion:
devzone.nordicsemi.com/.../using-multiple-uart-instances-with-app_uart-_fifo-_init

And when I take a look in the documentation for APP_UART_DRIVER_INSTANCE there is only option 0 available:
infocenter.nordicsemi.com/index.jsp
But I think it is because other SoCs don't have UARTE1 and with nRF52840 it seems to work with:
#define APP_UART_DRIVER_INSTANCE 1

#define APP_UART_DRIVER_INSTANCE 0 leads to an error because the CLI from Thread uses UARTE0. This is why it is set to UART0_ENABLED=0 in the preprocessor definitions for Thread-projects with CLI.

What I still don't get is, does the CLI from OpenThread uses the app_uart module? And if so and I change the APP_UART_DRIVER_INSTANCE to 1 will it affect the OpenThread CLI too, so that I will get maybe problems later here?

Regards
Markus

[Edvin]

MarkusK said:

What I still don't get is, does the CLI from OpenThread uses the app_uart module?

I am not sure exactly how the UART is used (app_uart or raw UART peripheral). 

MarkusK said:

And if so and I change the APP_UART_DRIVER_INSTANCE to 1 will it affect the OpenThread CLI too, so that I will get maybe problems later here?

I don't think so. Try it out and see if you can use UART1 while still using UART0 for the CLI. 

If there are some parts of app_uart that is hardcoded to use UART0, then that is probably just remaining bugs from older devices only having one UART, yes. If you have any issues when trying to set up app_uart on UART1, please let me know, and I can have a look. Please give some details on what the issues are in that case. 

Best regards,

Edvin