STM32H7 UART issue

[Sebastien Lorquet <se...@lorquet.fr>]

Hi,

I'm copying below the text of github issue #7138 I just opened, so that 
more people can help.

I think this is quite an important bug to be fixed for the quality of 
all upcoming releases.

Sebastien


Hi,

The stm32h7 does not properly drain the UARTs on close().

The console works perfectly and hides the problem, because nsh keeps the 
UART opened indefinitely.

However, a custom program that sends data to an UART sporadically (like 
the built in command echo or an application that open/write/close) shows 
this important issue.

echo does not even emit anything if I write less than 16 characters, 
which happens to be half the DMA buffer / cache line size (no idea if 
this is related). This is not a buffering issue as sending several small 
chunks in succession does not lead to the delayed emission of a large block.

in my program, cfmakeraw does not change anything.
calling tcdrain before close does nothing either.

Inserting a one second delay after a serial write ( with sleep(1) ) 
allows my output to be written.
Leaving the UART open in my program does not help, since the devices are 
closed after the program ends. This also happens in the echo command.

Disabling DMA peripherals and options entirely has no effect and I dont 
think it's wise since the serial driver and others parts of the stm32h7 
serial code clearly assumes DMA is enabled.

I wonder if there are bugs in the stm32h7 driver, specifically related 
to DMA or something else, or if the issue is known, or if I missed some 
config options.

Any help investigating this is highly appreciated, since the serial 
driver is surprisingly complex and I do not know how to start debugging 
this dynamic issue.

It can probably be reproduced in ANY stm32h7 board with a secondary uart 
and the echo command.

Thanks

Sebastien