Dear NCS team,
I am developing an asynchronous UART driver using ncs v3.1.1. I observed that when calling uart_rx_enable() with a timeout value of 100 µs (at 115200 baud, where one byte ~87 µs), I received frequent UART_ERROR_FRAMING events, even though the physical connection is good.
After analysis, I suspect that the hardware timeout (UARTE TIMEOUT register) may expire during the stop bit of the current byte when the timeout is set too close to the theoretical single‑byte duration. This would cause the UARTE to terminate reception before the stop bit is fully sampled, leading to a framing error. Additional factors include integer rounding in the driver (baud‑to‑tick conversion), clock tolerances between the two ends, and oversampling jitter.
To verify this, I increased the timeout to 5 ms, and the framing errors disappeared completely. This confirms that the hardware is working correctly, and the issue is indeed the marginal timeout value.
Given this, I have two practical questions:
-
Is there a recommended minimum safe timeout for 115200 baud (8N1) that you would advise, considering clock tolerances and driver overhead? I tested 1 ms and 2 ms – both appeared stable, but I would like an official guideline.
-
For protocols like Modbus RTU, where the inter‑frame gap must be less than 3.5 character times (~304 µs at 115200), is it feasible to use a timeout around 300–500 µs without risking framing errors? Or would you suggest enabling hardware flow control or using a different approach (e.g., DMA counter polling) for such low‑latency requirements?
Additionally, I made sure the RX pin is pulled up (via bias-pull-up) and the buffer length is sufficient, so those are not contributing factors.
Could you please confirm whether my understanding is correct and whether there are any known driver limitations or hardware constraints I should be aware of? Any advice on achieving a reliable, low‑timeout setting would be greatly appreciated.
Thank you for your support.
Best regards,
