Hi!
We have recently upgraded nRF Connect SDK. Since this change, some of our users experience issues with uart - two nRF52840 communicating together. We have not been able to reproduce the issue and the users aren't very responsive, so we unfortunately don't have solid data or solid testing environment.
I would like to inquire if this report rings any bells? (I.e., any hypotheses of what might have gone wrong and may be worth testing or looking into.)
(We know this is not sufficient and don't expect much time to be invested into this, still, advice would be appreciated.)
Setup (compiled by an ai agent):
- The jump is nRF Connect SDK v2.8.0 → v3.3.0 (Zephyr 4.3.99, ncs-v3.3.0 fork).
- Hardware: two nRF52840 boards linked by UARTE1 in both directions over a cable, 115200 8N1, no flow control.
- API: Zephyr async UART API (uart_rx_enable, uart_rx_buf_rsp, uart_tx), two alternating RX buffers, RX timeout 700 µs.
- Driver config:
- CONFIG_UART_NRFX_UARTE=y, CONFIG_UART_1_ASYNC=y
- CONFIG_UART_1_NRF_HW_ASYNC=y, CONFIG_UART_1_NRF_HW_ASYNC_TIMER=1
- CONFIG_UARTE_NRFX_UARTE_COUNT_BYTES_WITH_TIMER_LEGACY=y
- CONFIG_UART_NRFX_UARTE_ENHANCED_RX not set
- CONFIG_UART_1_NRF_ASYNC_LOW_POWER not set, CONFIG_PM_DEVICE=y
- Traffic: short framed messages with CRC, single-byte acks, a ping every 200 ms; the line is idle most of the time.
Some context and findings:
- Uart support in the SDK has been rewritten during this version jump.
- Limited version of similar problem can be reproduced by a simultaneous cold start of both boards. In that case, one nRF52840's UARTE async receiver delivers a wrong first byte after every idle gap on the line, with no error event, until RX is disabled and re-enabled once. Fixing this doesn't make the above issue go away though.
