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

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

helpfulchicken — Sat, 13 Sep 2025 22:59:59 GMT

I had a similar issue (I think, I may be wrong in my understanding of your issue) where using the asynchronous UART driver I would get missed and corrupted bytes received.

I stumbled on a solution to my issue in some sample code.

While using async UART API:

CONFIG_UART_ASYNC_API=y
CONFIG_UART_INTERRUPT_DRIVEN=n

I would see corrupted and missed Rx bytes intermittently.

I found that the issue went away if I added the following:

CONFIG_UART_0_ASYNC=y
CONFIG_UART_0_INTERRUPT_DRIVEN=n
CONFIG_UART_0_NRF_HW_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2
CONFIG_NRFX_TIMER2=y

CONFIG_UART_1_ASYNC=y
CONFIG_UART_1_INTERRUPT_DRIVEN=n
CONFIG_UART_1_NRF_HW_ASYNC=y
CONFIG_UART_1_NRF_HW_ASYNC_TIMER=3
CONFIG_NRFX_TIMER3=y

In my use case, I am using both uart0 and uart1.

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

Håkon Alseth — Thu, 12 Jun 2025 14:10:26 GMT

Hi Nathan,

I was recently made aware that this scenario has now been reproduced internally, as also shared by my colleague in the linked thread here:

Zephyr async uart driver corrupts data on UARTE frame timeout

We are currently investigating, but I can unfortunately not share any details at this time, but please send me a direct message if this is blocking your development, and I will put you in contact with the sales rep. for your area.

Kind regards,

Håkon

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

Nathan Boyd — Thu, 12 Jun 2025 02:08:46 GMT

Hi Nick, Sathiya,

Nick's comments about the handling of the frame timeout seem to be closer to what I am seeing. I did try tuning the rx timeout, but the device I am receiving from has inconsistent timing. I haven't 100% tracked down which portion of data (and associated idle periods) are triggering my problem.

I may take a look at the driver code more closely, as I did see a similar problem on an Energy Micro device that didn't have an in-built rx timeout, but I was able to use a general purpose timer (reset on each byte receive) to detect a timeout and force the dma to switch buffers. When I didn't have this working properly (incorrect relative priority of the UART interrupt and the TIMER interrupt), I got lost data due to some of the dma state being incorrect (data was received, but not processed), mainly as the DMA engine didn't keep track of received bytes per buffer, just the state of the active DMA transfer).

I am going to try:

- Getting rid the disabling of the RX on an error. I didn't get this working (or it didn't help) before.

- Not handling the FRAME_TIMEOUT_STOPRX and just trying to forward the partial data seen.

- I suspect there may be a race condition to avoid here to make sure the partial data is retrieved, but the frame timeout is restarted.

I have previously been trying to track down behaviour with some pretty heavy debug output, but I am considering trying to reproduce the problem with plain ascii, and putting some non-ascii data in the stream to indicate when things have occurred (framing error, break).

I think it might be useful to know more about the 5 byte HW FIFO as well, which seems to feed the receive DMA. It isn't really documented, but can be inferred looking at the driver code (where, upon stopping RX, the DMA is completed, then the remains of the FIFO are drained manually.

Regards,

Nathan Boyd.

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

Nathan Boyd — Thu, 12 Jun 2025 01:49:31 GMT

Hi Hakon,

I have tried removing the disable line (without noticable improvement), but not in conjunction with some other changes. The project will be put on hold soon, so my investigation will be done in my own time.

If I find anything I will let you know.

Regards,

Nathan Boyd.

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

Nathan Boyd — Thu, 12 Jun 2025 01:47:11 GMT

Hi Dymtro,

No, I haven't solved the issue yet (the project I was working on has been refocused for a while, and while I could capture some data of the problem recurring, I couldn't replay the signal accurately enough to reliably see the issue.

At some point, the problem did seem to be related to particular bits patterns, where I suspected that the baud rate was a little off. Further testing showed that wasn't the case for me (or at least I had other problems).

Normally, the baud rate being off (even past the normally stated 2% precision) isn't much of a problem, but I did see at least one device years ago that took a little longer to recognise the start bit (required about 1.1 stop bits to reliably receive), and that seem to affect the resyncing the bit bit clock. In that case setting the other end to 2 stop bits (something I can't do with the device I am receiving from now) made everything %100 reliable.

In that case, I saw problems with the MSB being zero, with part of the MSB (sent last) being interpreted as the stop bit, which caused the error.

Many USB to UART adapters can bunch up data, leading to no gap between the stop bit and the following start bit, which should be OK.

Regards,

Nathan Boyd

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

Nick Ewalt — Wed, 11 Jun 2025 23:20:50 GMT

See devzone.nordicsemi.com/.../zephyr-async-uart-driver-corrupts-data-on-uarte-frame-timeout

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

Nick Ewalt — Tue, 10 Jun 2025 22:20:59 GMT

I am seeing the same behavior on NCS 2.9.0. If the delay between two bursts of data is equal to the frame timeout then the receiver will drop about 5 bits of data at 115200 baud, which can lead to framing errors and/or corrupted data. I believe that the issue is that the duration between the RX being stopped by the FRAME_TIMEOUT_STOPRX short to the subsequent re-enable is too long, but I haven't had an opportunity to dig deeply into this yet.

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

Sathiya Lingam — Mon, 19 May 2025 09:40:04 GMT

Hello Nathan,

We encountered a very similar issue and had been following this thread closely. In our case, a framing error occurred unexpectedly, and a few bytes were lost in the following frame.

After analyzing the timing more closely, we noticed that the issue consistently happened when the interval between the end of the current frame and the start of the next frame was close to the configured frame timeout. The behavior then made sense: the RX reception stops and restarts when the frame timeout is triggered - right around the time the next frame begins transmission.

I'm not certain if this matches the issue you're seeing, but I thought it might be good to share our experience.

Best regards,

Sathiya

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

Håkon Alseth — Mon, 12 May 2025 08:01:26 GMT

Hi,

Your issue sounds like a different one, as this is a consistent behavior on your side, and it also sounds like it is repeatable in a given pattern/configuration. Could you please create a dedicated ticket with this behavior, and please share a sample/full configuration of your setup.

Kind regards,

Håkon

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

DmytroSes — Fri, 09 May 2025 13:51:46 GMT

Hello! I am facing the same issue with the NRF54L15 (I have checked it on the nRF54L15-DK).

I am using UARTE30 on the P0. I use the following configuration:
1200 bauds, 7 bits, even parity, 1 stop bit.

I get the framing error, but only when receiving the certain bytes. For example, I send the following ASCII sequence:
1234567 and always get framing error for the symbols 3, 5, 6. All other symbols are always received correctly.

This happens only when I use a USB-UART adapter (FTDI232 or CH340, does not matter). However, if I connect RX and TX pins on a DK, so it receives what it sends, everything works fine.

Did you manage to resolve the issue?

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

Håkon Alseth — Mon, 05 May 2025 14:49:40 GMT

Hi Nathan,

[quote user="Nathan Boyd"]

To be clear, I don't seem to lose any characters simply by being swamped, and the RX timeout seems to be handled correctly.

The problem seems to occur when there is a frame error, which results in the Nordic driver disabling RX, which then has to be re-enabled in the application (which is using the async driver interface). This means that not only a single "bad" character is lost, but potentially some others. The problem really seems to be in two parts:

[/quote]

Thank you for clarifying, this was very helpful for me to understand.

I believe that the issue is directly related to this function call in our driver:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.7.99-ncs3/drivers/serial/uart_nrfx_uarte.c#L1408

Right now, we stop the UART RX if a ERRORSRC event occurs, and then have to follow the whole sequence outlined in the zephyr uart.h API:

https://github.com/zephyrproject-rtos/zephyr/blob/v4.0.0/include/zephyr/drivers/uart.h#L188-L191

And this causes a larger delay for when you're able to re-enable the uart receiver in the application space.

For testing purposes:

If you comment out the disable line(uart_nrfx_uarte.c, line 1408), are you able to see improvements on the overall serial communication?

Kind regards,

Håkon

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

Nathan Boyd — Wed, 30 Apr 2025 05:32:17 GMT

Hi Hakon,

I am currently working on making an accurate signal capture so I can point out the timing of the byte sequences that trigger the framing error, so we can look at if there is any glitching or level differences that the logic analyzer couldn't show.

There probably isn't much point looking too deep into my previous reply until I can give you some hard data to reproduce the issue.

Regards,

Nathan Boyd.

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

Nathan Boyd — Wed, 30 Apr 2025 03:35:13 GMT

Thanks Hakon.

I am aware of CONFIG_UART_NRFX_UARTE_ENHANCED_RX, and it seems to be set correctly by default.

To be clear, I don't seem to lose any characters simply by being swamped, and the RX timeout seems to be handled correctly.

The UART detects a framing error when I don't expect one to be seen. In all my measurements so far, the sending device has good bit timings, but could possibly be a either a little short on the stop bit, or at least bang on with no extra delay. My current method for measuring this isn't accurate enough to be totally sure that the timing is always good (the logic analyser can sample at 8Mhz, which sometimes results in bit timings looking a little off, and small variances can't be seen, and I haven't caught a short bit with the oscilloscope yet.
When the framing error is detected, I seem to lose more than just the affected byte, presumably because the current RX is stopped, and it takes some time to restart it.

This is compounded by the protocol we are listening to being difficult to resync to with missing or corrupted characters, and the packet timing being quite variable under some circumstances.

I have done some more testing since my last post, and I may also be seeing corrupted characters, but it is hard for me to tell.

My concerns are:

The Nordic UART may not like a stream of bytes that are closely spaced, and may not detect the following start bit (either resyncing a little bit late, or missing that bit and then generating a framing error for the following byte). I can't quite tie it down, but it does look like the problem may show up when there are a lot of closely spaced bytes being received. I have seen such a situation below in some older UART hardware (I think it was the UART on an NXP ARM7 device), that meant that it actually required just a hair more than one bit time for a stop bit, otherwise the following start bit could be lost. This was only seen when receiving from a device that had no delays (many devices I tested at that time had significant gaps (ie multiple bit times) between transmitted bytes even when transmitted from a FIFO or via DMA. This caused a problem when a new peripheral was added to a product which had gapless UART transmissions, causing the NXP device to drop many bytes.
The disabling of RX on reception of an error by the Nordic UART driver somewhat thwarts attempts to resync the protocol.

The device we are listening to has vary variable behaviour it packet timings. It is a UHF RFID scanning module that has a stated behaviour of scanning to RFID tags for about 400ms, then reporting detected tags during an approx 100ms period, then scanning again. The behaviour is sometimes inconsistent:

When the UHF scanner module doesn't detect many tags, each packet is slightly spaced, and each byte in the packet follows immediately (i.e. the stop bit is immediately followed by a start bit, with no idle time).
When the UHF scanner is busier (more tags are detected), it seems to also transmit on the UART outside the 100ms period and the following is observed:
- Some packets have no idle time.
- Some packets are split into two pieces, with a large (10s of bytes worth) idle time between them. This usually has 2 or 3 of the bytes in one packet, with the rest in another.

The variability in the output from the scanner module makes it hard to reproduce faults, but when I tap off the RX signal and capture it on both a PC UART and logic analyzer, all data is reported good (but I am not sure if the logic analyzer cares if the stop bit is full sized).

When we first saw this problem on our nRF54L15 platform, I noticed that we were unadvisedly using UART30 (low power domain) on Port 2 (High Performance domain), and assumed that the detected framing errors were due to propagation time issues with that setup.

I don't believe I have seen the issue with long packets without idle time between bytes, but I am trying to force the issue by generating worse case data based on what timings I have seen from the scanner. The longest individual packet is only around 80 bytes, under the size of a single receive buffer, but because of the long delays chopping up packets when the scanner is busy, I suspect that the problem may occur in situations where the RX timeout comes into play.

If you can confirm that there is no likely issue with the UART receiving a large number of bytes without gaps between bytes (i.e. with start bit immediately following stop bit), either due to sync drifting, or performing a stop bit sample and check past the middle sample period of the stop bit, then I can pretty much write off the Nordic side and concentrate on the vendor of UHF scanning module.

It just seems suspicious that all the PC/USB UART and the logic analyzer are both receiving the data correctly without framing errors.

Regards,

Nathan Boyd

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

Håkon Alseth — Tue, 29 Apr 2025 13:44:12 GMT

Hi Nathan,

[quote user="Nathan Boyd"]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.

[/quote]

So right you are. My deepest apologies, I have written incorrectly. You are ofcourse free to use any available GPIO on P1, but UART2x peripheral has dedicated GPIOs on P2:

https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/uarte.html#d1900e814

Sorry for the mix-up on my side.

[quote user="Nathan Boyd"]

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.

[/quote]

This sounds correct.

nrfx_clock_start will route to either the driver, or the MPSL implementation (when MPSL is included).

Please note that nrfx_clock handles the PLL start/stop for nRF54L15 with ncs v3.0.0 (and newer):

https://github.com/zephyrproject-rtos/hal_nordic/blob/master/nrfx/drivers/src/nrfx_clock.c#L490

[quote user="Nathan Boyd"]

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?

[/quote]

The intention of the hardware is that the request of the CLOCK.PLL functionality shall be more automated, as described here:

https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/clock.html#ariaid-title2

However, there are two erratum, #20 and #39, that needs to be handled:

https://docs.nordicsemi.com/bundle/errata_nRF54L15_Rev1/page/ERR/nRF54L15/Rev1/latest/anomaly_L15_39.html

https://docs.nordicsemi.com/bundle/errata_nRF54L15_Rev1/page/ERR/nRF54L15/Rev1/latest/anomaly_L15_20.html

And I fully understand that this is complicated as compared to former nRF5-series devices.

Let me know if anything is unclear.

I believe your description here:

[quote user=""]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.[/quote]

Is crucial to the behavior. Is the scenario in such a way that the rx buffer on the nRF side is less than the max-size your companion host sends? What I am asking is if there is a pattern to when the application misses some bytes.

Are you using "CONFIG_UART_NRFX_UARTE_ENHANCED_RX"?

Here's the intention behind adding this enhanced rx mode: https://github.com/zephyrproject-rtos/zephyr/commit/399a235653518bc9b65c083f2e70cefa943aa4d9

Kind regards,

Håkon

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

Nathan Boyd — Mon, 28 Apr 2025 23:40:43 GMT

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.

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.

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

Håkon Alseth — Mon, 28 Apr 2025 13:39:59 GMT

Hi,

[quote user=""]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)?[/quote]

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).

[quote user=""]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?[/quote]

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).

[quote user=""]and constant latency mode enabled[/quote]

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