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