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

[Volker]

hi,
i am trying to use the async uart api on a nrf52840 for communicating to a quectel bg95 modem.
no matter which timeout or buffer-size i am using, i am experiencing the problem that that some (1-2) bytes of the modem response are not received (or forwarded via the api) when they are arriving ... they are received with delay, when the next response of the modem comes in.

so the usual communication flow to the modem is:
(1) request from nrf -> modem
(2) response from the modem -> nrf (usually ending with "\r\n")
(3) some delay
(4) next request from nrf -> modem
(5) next response from the modem -> nrf

when using the async api it happens very often, that one or both of "\r\n" of (2) are missing as long as the response of (5) is beginning to come in. then the response of (5) is prepended with the missing "\r\n" of (2).

[Volker]

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

[Susheel Nuguru]

Volker said:

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

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

[Volker]

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

[Susheel Nuguru]

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

[Volker]

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.