patacongo
commented
3 years ago t drops chars with HW flow control (on chip).
Isn't that due to the lack of RX/TX FIFOs on the serial peripheral? That causes this bad behavior if the chip hardware flow control is enabled: https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32/Kconfig#L9409 and https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32l4/Kconfig#L5656 (I guess you should know all about that since you added the FLOWCONTROL_BROLEN kludge).
The H7 (and maybe others) do have FIFOs and should not required the FLOWCONTROL_BROKEN kludge.
That little circular RX DMA was added by Mike Smith to account for data losses because of the lack of Rx FIFOs on the STM32 F4 family. It should not be necessary if the U[S]ART peripheral has hardware FIFOs. The original H7 did not support this circular DMA (as I recall) because it was not needed.
-
It does work correctly with GPIO flow control. :+1: It drops chars with HW flow control (on chip). :-1: It also drops chars with DMA with GPIO flow control. :-1: With DMA the test app hangs on close. :-1:
I noticed the DMA arrangement is not the same as F4, F7, H7, I suspect this is the root cause of the DMA issue.
The character loss may be fact that one octet can be in flight inbound and does need to be received, even after RTS is de-asserted. Another observation is the pin is named differently from the STM32F4...