Environment:
-
nRF Connect SDK (NCS): v3.1.0
-
Hardware: nRF54L15 (Custom/DK)
-
External MCU: S32K344 (sending data via UART @ 115200 baud)
-
Toolchain: Zephyr OS v4.1.99
Issue Description: I am implementing a custom UART-based OTA update. An S32K344 sends a binary image (approx. 50KB) to the nRF54L15 in chunks(chunk size: 256 bytes). The nRF54 receives these chunks via an interrupt-driven UART driver and writes them to the secondary slot using the flash_img API.
The transfer starts correctly, but it consistently stalls before completion. For example, in a 50,044-byte transfer, the logs show it hanging at exactly 39,931 bytes. Attached the config files and log screenshot for reference.
Symptoms Observed:
-
Data Corruption/Ghost Bytes: Even with error clearing, I occasionally see the
rx_lenjumping by 257 or 258 bytes when 256 were expected, suggesting framing or overrun issues. -
Flash Latency: The stall appears to happen because the
flash_img_buffered_writeoperation takes long enough to cause the nRF54's internal UART FIFO to overflow while the S32K344 continues to stream data.
Current ISR Implementation:
if (!uart_irq_update(dev)) return;
// Clearing errors to prevent interrupt loop
int err = uart_err_check(dev);
while (uart_irq_rx_ready(dev)) {
uint8_t temp[64];
int len = uart_fifo_read(dev, temp, sizeof(temp));
if (len > 0) {
// Buffer management logic here...
}
}
}
Questions:
-
Is it expected that the nRF54L15 UART FIFO will overflow during active flash writes at 115200 baud without hardware flow control?
-
I am planning to enable RTS/CTS (Hardware Flow Control). Does the nRF54L15 UART peripheral handle RTS de-assertion automatically at the hardware level when the FIFO is nearly full, or do I need to manage the RTS pin manually in software when the flash write starts?
-
Are there specific
Kconfigoptimizations for the nRF54 series to prioritize UART ISRs over flash write operations to prevent data loss?
