UARTE framing errors on NRF52840 instead of my data

RE: UARTE framing errors on NRF52840 instead of my data

RobMeades — Mon, 01 Jun 2020 08:37:03 GMT

OK, seems like the libUARTE does what Dmitry suggested. I'll do the same.

RE: UARTE framing errors on NRF52840 instead of my data

Jared — Thu, 28 May 2020 13:14:44 GMT

I get it. The usual method for receiving continuously data is to use our libUARTE driver which is made specifically for this reason. If you want any guidelines/examples on how to implement your own driver then I suggest reviewing our libUARTE driver and example in the SDK.

RE: UARTE framing errors on NRF52840 instead of my data

RobMeades — Tue, 26 May 2020 23:52:31 GMT

Unfortunately I can't rely on the user connecting the flow control lines, this must work with truly continuous data.

I was kinda hoping for an authoritative "this is how the HW is designed to be used" kinda answer, rather than a "what that guy said" kinda answer. But if the fruits of Dmitry's suffering is the truth, then I guess that's it.

Just seems a strange approach to explaining your own technology is all.

Thanks again Dmitry.

RE: UARTE framing errors on NRF52840 instead of my data

Jared — Tue, 26 May 2020 12:29:15 GMT

Hi,

I'm sorry for the lack on feedback on this. But I don't actually have a better tip then what has already been purposed in this thread. Is Hardware flow control not a possible option? Or would that contradict the continuous part in your project? Either way, I think using a counter that keeps track of the received bytes would be an alternative.

best regards

Jared

RE: UARTE framing errors on NRF52840 instead of my data

RobMeades — Tue, 26 May 2020 09:31:56 GMT

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

RE: UARTE framing errors on NRF52840 instead of my data

RobMeades — Wed, 20 May 2020 08:53:23 GMT

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

RE: UARTE framing errors on NRF52840 instead of my data

Dmitry — Wed, 20 May 2020 08:47:39 GMT

[quote userid="68812" url="~/f/nordic-q-a/61585/uarte-framing-errors-on-nrf52840-instead-of-my-data/250866"]Seems a shame to have to run a per-character interrupt just to count the things[/quote]

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

RE: UARTE framing errors on NRF52840 instead of my data

RobMeades — Wed, 20 May 2020 08:09:14 GMT

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.

RE: UARTE framing errors on NRF52840 instead of my data

Dmitry — Tue, 19 May 2020 18:09:41 GMT

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.