Framing error and noisy data when using UARTE at high baud rate

[moose]

Hello, in my zephyr application, I have uart1 configured as receive only using uarte at 921600 baud rate. Below is the description node:

&uart1 {
	compatible = "nordic,nrf-uarte";
	label = "data_uart";
	current-speed = <921600>;
	status = "okay";
	rx-pin = <30>;
};

 

I have a device sending a uart packet every 50ms and although I can see the right number of bytes being received, the data itself is corrupted (some bytes are correct but some are not) and I get a framing error thrown by the IRQ for every packet. I scoped the signal and it is very clean. I have also connected a terminal software (minicom) and I was able to receive the expected data while nrf52833 cannot. I do have another uart running on the same SoC (uart0) and that one is working fine but it is running at 115200 baud rate. I am not sure if I have to do anything special due to the high baud rate. I thought the DMA should help and I have allocated a timer for the byte processing. Here are my config statements:

#uart
CONFIG_SERIAL=y
CONFIG_UART_ASYNC_API=y
CONFIG_UART_0_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2
CONFIG_UART_0_NRF_ASYNC_LOW_POWER=y
CONFIG_UART_1_ASYNC=y
CONFIG_UART_1_NRF_HW_ASYNC=y
CONFIG_UART_1_NRF_HW_ASYNC_TIMER=4
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y 
CONFIG_CLOCK_CONTROL_NRF_K32SRC_20PPM=y

I thought maybe it is a clock issue but my understanding is the system automatically enables the HFCLK. The datasheet mentions a note about the pin drive strength for high baud rate but since I am not transmitting, I don't think this is related to my case. Please let me know if I am missing anything. Thank you.

[hmolesworth]

Well this is a surprise, the UART actually works at all baud rates up until 7.999Mbaud on transmit; receive only works up to 1MBaud however, as receive depend on the number of samples used (16 typically) although this is not quoted. I posted the full table in the edit above, but added this comment as otherwise it gets lost.

Recap on original post: 921,600 baud has a 2.124% error using the incorrect value quoted in the data sheet and the SDK code, assuming my calculations are correct. +-2% is as far out as a asynchronous serial port should be allowed to get. Depending on whether the UART uses 3- or 16-sample voting to determine whether a bit is '0' or '1' and the slope of the initial start bit falling edge and any externally introduced noise on that edge means start bit timing determination could be 10% or more off; the next start bit 10 bits later adds 10x2.124=21% to this error (now 31%) before the relative (ie different) clock accuracy at both ends of the link is considered. Assuming 10-bit Tx (send full stop bit) and 9.5-bit Rx (receive half stop bit) that's a risky error as 50% total of all errors is the threshold where framing errors will occur.