Asynchronous UART API (DMA) not working like expected on nrf52840

RE: Asynchronous UART API (DMA) not working like expected on nrf52840

Volker — Wed, 27 Jul 2022 12:22:49 GMT

Finally I managed to find the solution by myself:

add the following lines to prj.conf:

CONFIG_UART_0_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC_TIMER=0

some kind of documentation about this would have helped me a lot.
menuconfig did not help either, because when setting the timer instance number there, compilation fails afterwards.

RE: Asynchronous UART API (DMA) not working like expected on nrf52840

Volker — Tue, 26 Jul 2022 15:23:42 GMT

The async uart dma driver counts the RXRDY events which are raised by the nrf-hardware immediately after detecting a fully received byte, but potentially before transferring it to the dma memory buffer (see nrf52840 datasheet). This counting is done within an ISR. And this counted value is used by the driver logic when executing the timer-timeout event.

There is some comment within the driver source code (around line 1075 in uart_nrfx_uarte.c) that it might happen that this counting is wrong due to latencies in handling interrupts.

With the debugger I can confirm, that the driver falls into this "if (len<0) {...}", where wrong counts are handled, in the case that the problem occurs.

It does not fall into this branch, when CONFIG_NETWORKING is disabled.This is the case where everything works fine.

So for me it seems that CONFIG_NETWORKING does some ISR handling which takes too long time, blocking the RXRDY isr handling for too long time, which leads to wrong byte counting.

CONFIG_NETWORKING adds quite a big amount of source code to the project, therefore I am kind of lost where to look for the long-lasting isr handling.

So I would really appreciate any hint for how to get out of this problem!

RE: Asynchronous UART API (DMA) not working like expected on nrf52840

Volker — Fri, 22 Jul 2022 13:54:33 GMT

I made an interesting experience:
The async dma uart handling works fine until the "CONFIG_NETWORKING" config option is added to the prj.conf file.
Building and running the identical application code, it then runs into the described problem.

I tried the app without CONFIG_NETWORKING ... then I had no problem with sending/receiving 2000 AT-commands to/from the modem.

After adding CONFIG_NETWORKING with no other change ... then the app ran into the problem while waiting for the first two status messages from the modem.

Networking is unfortunately required as the application is going to use mqtt as communication protocol.

RE: Asynchronous UART API (DMA) not working like expected on nrf52840

Susheel Nuguru — Thu, 21 Jul 2022 12:02:31 GMT

thanks for trying that out. Please update this thread once you find out the issue so that this thread can be complete.

RE: Asynchronous UART API (DMA) not working like expected on nrf52840

Volker — Wed, 20 Jul 2022 14:53:26 GMT

With the standallone demo example, I am not able to reproduce the problem.

So there must be some side-effects from other software running in parallel.

I have to investigate this further ...

RE: Asynchronous UART API (DMA) not working like expected on nrf52840

Susheel Nuguru — Wed, 20 Jul 2022 11:55:37 GMT

[quote user="Volker"]I can try to prepare some isolated example for a nrf52840dk eval board. Would that help?[/quote]

That would help a lot. Thanks, will wait for your minimal example to reproduce the issue and debug on my desk.

RE: Asynchronous UART API (DMA) not working like expected on nrf52840

Volker — Wed, 20 Jul 2022 06:50:50 GMT

#define QUD_RX_QUEUE_ENTRY_INIT \
{                               \
    .data = { 0 },              \ 
    .length = 0                 \
}

typedef struct Qud_RxQueueEntry_Tag Qud_RxQueueEntry_T;
struct Qud_RxQueueEntry_Tag
{
    uint8_t data[ 8 ];
    uint8_t length;
};

The "e" variable is a local variable of a struct type, containing data bytes and length.
As this variable is local and immediately put into a queue, I cannot imagine, that there is some accessing problem.

I can try to prepare some isolated example for a nrf52840dk eval board. Would that help?

RE: Asynchronous UART API (DMA) not working like expected on nrf52840

Susheel Nuguru — Tue, 19 Jul 2022 17:34:44 GMT

That kind of issues normally happens in some variables (normally global variables) when accessed in different contexts.

In you code

k_msgq_put( &Qud_rxQueue, &e, K_NO_WAIT );

Check how you declared "e" and how you are accessing it. It looks like there could data access issue. I cannot be sure that the issue is just with this variable, but there is not much code to review. In any case, i am quite confident that the issue is most likely in the code changes you did in your application. It would help to attach the whole setup (files) so that I can replicate this issue and assist you better.

RE: Asynchronous UART API (DMA) not working like expected on nrf52840

Volker — Tue, 19 Jul 2022 15:59:06 GMT

After some more hours of testing the problem occurred also in release mode. But substantially less often.

RE: Asynchronous UART API (DMA) not working like expected on nrf52840

Volker — Tue, 19 Jul 2022 12:14:50 GMT

I made the observation that the problem seems to show up only in debug mode. When building in release mode, I cannot see that kind of problem.
In our configuration the debug mode is mainly specified as:

CONFIG_DEBUG=y
CONFIG_SIZE_OPTIMIZATIONS=n
CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_ASSERT=y
CONFIG_LOG=y

RE: Asynchronous UART API (DMA) not working like expected on nrf52840

Volker — Tue, 19 Jul 2022 06:52:54 GMT

static void Qud_Init()
{
    uart_callback_set( Qud_uartDevice, 
                       Qud_DmaUartCallback, 
                       NULL );

    uart_rx_enable( Qud_uartDevice,
                    dmaBuffer->data,  
                    sizeof( dmaBuffer->data ), 
                    1000 /* us */ );
}




static void Qud_DmaUartCallback( const struct device* dev,
                                 struct uart_event*   evt,
                                 void*                user_data)
{
    switch ( evt->type )
    {
        case UART_RX_RDY:
            {
                Qud_RxQueueEntry_T e = QUD_RX_QUEUE_ENTRY_INIT;

                e.length = evt->data.rx.len;
                memcpy( e.data, 
                        &( evt->data.rx.buf[ evt->data.rx.offset ] ),
                        evt->data.rx.len );

                k_msgq_put( &Qud_rxQueue, 
                            &e, 
                            K_NO_WAIT );
            }
            break;
            
        default:
            break;
    }
}

There is also a logic analyzer connected. The modem sends the data properly.

As mentioned in my post before: The data is not lost, but it is received with a more or less big delay .... depending on point when the modem sends the next bytes (usually part of the next command).

The code is part of a battery-powered device, where the activation time of the modem is quite critical for the overall power-consumption. Therefore we are interested in having as short delays as possible during the modem communication.

As the uart-callback function is called from an isr-context I tried various different message passing variants. It seemed that all of them did not make any difference for this problem. The one here uses a very simple message queue without any optimizations.

RE: Asynchronous UART API (DMA) not working like expected on nrf52840

Susheel Nuguru — Tue, 19 Jul 2022 05:00:21 GMT

Can you please post some code snippets of how you have initialized the asyn uart and code snippets to show transfers from nrf side.

Have you already verified on the the modem transmit lines (using logic analyzer of oscilloscope) that modem is sending the data correctly?