UARTE framing errors on NRF52840 instead of my data

[RobMeades]

I have written a UART driver that is intended to receive data in a continuous stream.  I know it basically works as it is able to communicate with an external device at 115,200 bits/s. I am now performing more rigorous testing.

I have a very simple HW setup with the UART Tx/Rx on pins p1.10 and p1.11 of the NRF52840 DK board looped back to each other; perfect electrical conditions.  My test code is transmitting data from the UART continuously and receiving data back in an RTOS task.  My driver has a 135 ms timeout, necessary for the case where data is received in bursts, which disables the ENDRX_STARTRX short and triggers STOPRX.

My problem is that after the RXTO event occurs as a result of my timeout, the rest of my data is received back as framing errors, not actual data.  All I do in the RXTO interrupt is re-enable the ENDRX_STARTRX short and trigger the STARTRX task.  FYI I do call nrfx_clock_hfclk_start() at start of day.

So something is wrong.  Question is, what is the right way to do this, to implement continuous UART receive while dealing with the fact that there may be breaks in the received data and that cannot leave stuff lying stale in the UART Rx buffer?  Should I be re-enabling the ENDRX_STARTRX short and re-triggering the STARTRX task earlier somehow?  I have tried setting a flag when the timeout has occurred and doing the re-enabling/triggering in the ENDRX interrupt instead but that didn't seem to help.

The complete driver code can be found here: https://github.com/u-blox/cellular/blob/master/port/platform/nordic/nrf52840/src/cellular_port_uart.c.

[Dmitry]

Hi,

I have also written an UART receiver, after having the hell of missed bytes and loss of sync, I came to conclusion that STOPRX should not be called when receiving a continuous stream. Instead, create two buffers and set ENDRX-STARTX shortcut for all the time. You will face another issue - there's no way to know how many bytes are already received until whole buffer is filled. The solution is to set up a counter on RXDRDY event.

[RobMeades]

That's really interesting, thanks. Seems a shame to have to run a per-character interrupt just to count the things but if needs must.

To the Nordic guys: before I begin my fourth design, you MUST have a design pattern for this?  It is the default scenario: receive a stream of bytes of unknown length/periodicity.  I've managed to begin and complete a port to STM32F4 in the time I've been trying to do this on NRF52840, and the STM32F4 is a much more complex chip: I was only able to do it because ST had a design pattern to help me out.

[Dmitry]

RobMeades said:

Seems a shame to have to run a per-character interrupt just to count the things

You don't need an interrupt for every character, just a PPI channel to the timer working in counter mode.

[RobMeades]

Oh, OK, I'll take a look at that...

[RobMeades]

<non-Corona virus, just polite "cough"/> Nordic team?