Bit loss on NRF52840 UARTE at 115,200

RE: Bit loss on NRF52840 UARTE at 115,200

RobMeades — Mon, 04 May 2020 17:00:49 GMT

Ooo, good spot, I was calling nrf_drv_clock_init() but wasn't asking for the HF clock, I had missed that entirely. Starting the HF clock definitely seems to have improved things, though now I'm seeing the single character loss issue again, which I guess was being masked by this.

Still, many thanks for your insight, closing this call.

RE: Bit loss on NRF52840 UARTE at 115,200

Dmitry — Mon, 04 May 2020 16:21:11 GMT

One more thing to check - did you start HFCLK? As nRF52840 spec says, 'External crystal oscillator must be enabled to obtain sufficient clock accuracy for stable communication."

RE: Bit loss on NRF52840 UARTE at 115,200

RobMeades — Mon, 04 May 2020 16:05:33 GMT

FYI, I have measured the received character rate as seen by the Saleae logic probe and I'm receiving 10 characters (i.e. each consisting of one start bit, eight data bits and one stop bit) in 0.869 ms, so I make that a rate of 115,074 or just 0.1% error. So I don't believe the far end is at fault, there must be something wrong at my NRF52840 end.

RE: Bit loss on NRF52840 UARTE at 115,200

awneil — Mon, 04 May 2020 15:44:54 GMT

Oh - I see.

RE: Bit loss on NRF52840 UARTE at 115,200

RobMeades — Mon, 04 May 2020 15:29:49 GMT

I think the problem is that the AT modem is now expecting 2 stop bits (i.e. the setting is bidirectional), which it is not getting unless the NRF52840 UART is set up the same way.

Thanks for the suggestion though, it was a good idea to check.

RE: Bit loss on NRF52840 UARTE at 115,200

awneil — Mon, 04 May 2020 15:19:23 GMT

I was suggesting it as a test rather than a solution.

Adding extra stop bits at the sender should not require any change in the receiver - a Stop bit is indistinguishable from line idle.

RE: Bit loss on NRF52840 UARTE at 115,200

RobMeades — Mon, 04 May 2020 15:09:41 GMT

Unfortunately this is multi-platform code intended to work with multiple chipsets (i.e. other than NRF52840) and multiple AT modems so the answer is "not without a lot of pain".

In this particular instance I can hack the AT modem by sending it an AT command to switch it into sending 2 stop bits but that stops everything working unless I also set 2 stop bits on the NRF52840 side and, curiously, the NRF API omits the ability to do that (nrf_uarte_configure() doesn't include a "number of stop bits" parameter). If I hack that as well by writing to the register directly then of course it doesn't work to begin with because the AT modem doesn't initially send two stop bits it has to be told to do so via an AT command, etc...

So it would be a last resort as I would have to introduce platform dependencies up in the generic AT driver code.

Running a pair of UARTs talking to each other at 115,200 shouldn't be much of a strain on the system: is there anything I might configure on the NRF52840 side to improve matters?

RE: Bit loss on NRF52840 UARTE at 115,200

awneil — Mon, 04 May 2020 14:44:25 GMT

can you get the sender to add an extra Stop bit? or an inter-character delay ... ?

RE: Bit loss on NRF52840 UARTE at 115,200

RobMeades — Mon, 04 May 2020 14:40:34 GMT

An excellent question, I should have thought to check that.

Dumping the return value of nrf_uarte_errorsrc_get_and_clear() in the NRF_UARTE_EVENT_ERROR part of the interrupt into an array and printing the values out afterwards, when there is no problem I get no error events and when the problem occurs I get alternating framing errors/breaks followed by lots of framing errors, something like this:

framing error
framing error
break
framing error
break
framing error several 10s of times

RE: Bit loss on NRF52840 UARTE at 115,200

awneil — Mon, 04 May 2020 14:01:39 GMT

Are you getting framing errors reported by the UART ?