UARTE Framing errors after triggering STOPRX task

[Ilya Kondrashkin]

We are trying to implement UART driver that will work together with SoftDevice. We can't use UART or UARTE with single-byte buffers since high-priority task like SoftDevice will cause data loss.
The main idea is to use big RAM buffers for UARTE and switch them using short-cut ENDRX->STARTRX and calling periodically STOPRX task. The approach is very similar to libUARTE async library
The problem is that we see Framing errors when we call STOPRX (causing short-cut ENDRX->STARTRX). Framing error don't happen if we use just this big buffers and have they switched by filling up (do not call STOPRX task, n). We have lost a couple of bytes with framing error.
We checked the actual UART input using oscilloscope when such a framing error happened in software and it was perfectly fine, the only difference is that we were triggering STOPRX task periodicaly.

PS: As far as I read around here triggering STOPRX potentially can cause loss of data. Don't clearly understand why, but anyway. Is it possible to just switch buffers by other way?

[Einar Thorsrud]

Hi,

You cannot use STOPRX like this, as explained here. Do you need to receive an arbitrary number of bytes and/or count bytes are you are receiving them? If so, using libuarte in a timeslot could perhaps be an alternative? This way you will be guaranteed not to be interrupted by the SoftDevice. Other interrupt sources you would have to handle yourself.

If you do not need to handle an unknown number of bytes, then you can use the UARTE peripheral as normal, using DMA so that the CPU is only needed to set up the transaction, but not while it is ongoing.

Regarding switching buffers, the .PTR and .MAXCNT registers are double buffered so you can prepare for a new buffer, but you cannot change buffer in the middle of a transaction, only at the beginning of a new one (see UARTE chapter in PS).

[Ilya Kondrashkin]

We do not know actual number of bytes we are receiving and we use SoftDevice so the task was kinda tough. Also we need to implement POSIX-like interface (simple read with timeout for whole read request) so we can't use libuarte. But we have already written the driver that covers our needs.
Thanks for the answer!