Framing Errors seen on nRF54L15 UART. Is it super sensitive to stop bit timing?

[Nathan Boyd]

Hi,

I am getting framing error notifications from the nrfx uarte driver on a zephyr platform when receiving data from a certain external device, but only when there are large bursts of data.

The data is at 115200bps, 8 bit, no parity, so not particularly fast.

The device I am receiving from has very tight timing (the stop bit is exactly one bit time well within tolerance), and often sends large (multiple hundreds of bytes) streams with no idle time between stop bit and following start bit. This device cannot have its serial settings modified (to increase the number of stop bits to 2 for example).

Looking at the data with both an oscilloscope and a very oversampled logic analyser (which will report formatting problems), the actual data on the line seems fine, but I can't be sure that it is consistent.

When I look at the data received from the driver, I generally just see missing bytes, rather than bad data (with a few exceptions), which seem to come from the data being dropped when the driver cancels the rx, and I suspect that I can't re-enable it fast enough.

As far as I can tell, I have the external oscillator enabled, and constant latency mode enabled, but I am not sure if there is any interplay with the nordic/zephyr code that may be altering this.

I am using the zephyr async API, with a slab buffer with 8 128 byte receive buffers handled, which seems to me to be the highest performing approach.

I have previously seen some UARTs which required ever so slightly more than a single bit time for the STOP before a new START bit, with very similar symptoms to what I have seen here.

My questions are:

• Is the baud rate divisor in SDK 2.9.1 for 115200 bps still correct? I have noticed that there are forum posts that state that this shouldn't be modified, but also that it doesn't line up with the formula also reported on the forums. Is the special adjusted baud rate divisor only for running from internal RC oscillator (and therefore tuned to it)?
• Is there a surefire way to disable any change on clock source/latency settings so that I can be sure that I am testing under the correct conditions?
  
  

My concern is that effectively the same code was talking to a cellular modem at a much high baud rate with total reliability, suggesting to me that the UARTE hardware might be a bit fussy about stop bit length.

Regards,

Nathan Boyd

[Håkon Alseth]

Hi,

 

Is the baud rate divisor in SDK 2.9.1 for 115200 bps still correct? I have noticed that there are forum posts that state that this shouldn't be modified, but also that it doesn't line up with the formula also reported on the forums. Is the special adjusted baud rate divisor only for running from internal RC oscillator (and therefore tuned to it)?

divisor is unchanged for 115k2, but there has been issues related to uarte2x, and running this on cross-powered domains, ie. crossing it into GPIO domain P1, where you are required to use constant latency (CONSTLAT).

 

Is there a surefire way to disable any change on clock source/latency settings so that I can be sure that I am testing under the correct conditions?

request the HFXO (like done here https://github.com/nrfconnect/sdk-nrf/blob/main/samples/peripheral/radio_test/src/main.c#L28-L48), and the baud should be quite accurate (~100 Hz off: https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/uarte.html#ariaid-title75).

 

and constant latency mode enabled

Are you using nrfx_power_constlat_mode_request to request this? This is important if you are using BLE, as this will ensure that the SoftDevice does not disable constlat.

 

Have you tried to use hw-flowcontrol?

 

Kind regards,

Håkon

[Nathan Boyd]

Hi Håkon,

• I didn't think was running cross domain. I am using uarte21, with pins on port 1 (both on the PERI PD). We were previously using a cross-domain setup, and thought that was the root of our issues.
  • So is UARTE21 not on the same domain as GPIO P1? I was checking against Figure 1 in the datasheet.
• I am currently using nrfx_clock_start(NRF_CLOCK_DOMAIN_HFCLK); I will compare to the example to see if it is any different.
• I am using nrfx_power_constlat_mode_request to enable constant latency. After my post, I found that someone reported that the CONSTLATSTAT register def was wrong, which explains why I wasn't confident that the setting was being done.
• RE: Flow control. Unfortunately we can't use flow control, as the attached device does not support it. The protocol does have CRC protection, so we can detect bad data, but because it doesn't use byte stuffing or bit stuffing, re-syncing to a valid start of packet is troublesome.

If it helps, my setup is:

• Using the nRF54L15dk board, connected via the pin headers to replace a Fanstel BM15 module on our own board (due to Fanstel using an out-of-spec XTAL).
• The UART we are using is UARTE21. Pins are P1.13 for TX, P1.14 for RX.
• We are setting constant latency.
• I _think_ we are correctly using the external XTAL for the HFCLCK.

The clock setup on the nRF54L15 seems quite different to the nRF5340 (which we previously prototyped with), notably there seems to be no explicit setting to select the source of the HFCLK between the internal RC and the external XTAL. 

• Am I correct in understanding that simply starting the XO and PLL in CLOCK is enough to force the use of the external XTAL?

I will study the example provided and let you know if it helps.

Regards,

Nathan Boyd.