Hello,
I am trying to interface the STM32U5 Nucleo board (STM32-U575ZI-Q) with a PC tool (Python-based) connected physically with a USB to TTL Serial 3.3V converter. The goal is to transfer an entire file over UART to the Nucleo board. I have made the following modifications to the example project (UART_TwoBoards_ComIT:(
- Set the UART baud rate to 921600.
- Enabled hardware flow control.
- Updated the code to handle larger data transfers.
The modified code is available on my GitHub fork: akhilpanayamparambil/STM32CubeU5 at ap/uart_test.
I am encountering an issue where, when the data size sent from the U5 board to the PC tool is increased to three times the initial size in aTxBuffer, the code hits the Error_Handler during HAL_UART_Transmit_IT. This also happens when I add a HAL_Delay(100) in the main loop.
When enabling hardware flow control for UART with a baud rate of 921600, the code hits Error_Handler when there is still data coming into RX even when RTS goes high.
Adding few screenshots of the transfer.
Code snippet of python script below.
Has anyone experienced similar issues or have any insights on how to resolve this?
Thank you!
I’m experiencing the same issue, even when using the RX Fifo (which the example does not use by default).
I believe this is happening because RTS flow control is only asserted when either the buffer or FIFO is full. This means that any byte received after RTS assertion will cause an overflow error. However, since RTS isn’t asserted until the previous byte is fully received, if the host is already sending the next byte this byte will result in an overflow.
Here’s an example where you can see RTS assertion in yellow and host byte transfer in blue. The hardware is not asserting RTS until there’s no space left in the buffer, and the next byte received results in overflow.
There’s already a FIFO threshold programmed when using FIFO mode, ideally the flow control would use this to ensure that a byte or two sent after de-asserting RTS would allow the transfer to complete successfully.
I’ve been able to demonstrate this with https://github.com/Trellis-Logic/STM32CubeU5/tree/uart-test-rx including a hack at https://github.com/Trellis-Logic/stm32u5xx_hal_driver/commit/6b009909b726aaa786217cfe91f846673274abed to use the FIFO threshold to hold off the host while bytes still remain in the FIFO.
With this change I can insert a variable delay at https://github.com/Trellis-Logic/STM32CubeU5/blob/c3dff424630d16360e91d035726f90c4c1944e7b/Projects/NUCLEO-U575ZI-Q/Examples/UART/UART_TwoBoards_ComIT/Src/main.c#L190 which does simulated processing in the main loop for between 1-14 ms while the buffer transfer itself only takes 10ms. The resulting flow control shows that the host is only blocked for portions of the transfer which occur when waiting for 11, 12, 13, or 14ms, the rest of the time the transfer is fully overlapped with the delay. Also, no bytes are lost and exactly the number of bytes sent by the host are received by the device
My question is:
- Is this expected behavior?
- Is there another/better way to prevent the host from sending bytes while processing for a variable amount of time in the main loop without resulting in overflow and ideally using the hardware flow control already supported by the device?
FWIW I believe we had similar code on the H7 series previously which used hardware flow control and which did not experience receive overrun or dropped bytes. I’m not sure if there’s a difference between series which would explain this. I didn’t see anything obvious in the errata.
