UART DMA Issue on STM32U5 Series #4452
Description
I recently noticed some odd behavior coming from the Async UART interface using a STM32U5-series chip (specifically the STM32U575ZIT6Q). If the DMA transfer is interrupted (for example, when using idle line detection as in read_until_idle), then the data from the peripheral becomes corrupted in often unpredictable ways.
My main concern here is that this issue may indicate a larger issue with the DMA implementation not limited to the UART peripheral which could cause state/memory corruption issues. However, I have not had the time to investigate whether this issue is reproducible on any other kind of peripheral.
I catalogue this behavior and provide a minimum reproducible example in this repository, so feel free to take a look and ask any questions. I'll try to answer them as well as I can. To repeat it here: multiple reads to the same buffer will introduce leading zeroes equal to the incoming message length. For example, the first call to read_until_idle yields Read Amount: 2, Data: [0xCA, 0xFE] while the second yields Read Amount: 4, Data: [0x00, 0x00, 0xCA, 0xFE] despite the same values [0xCA, 0xFE] being sent both times. If the memory address changes at all, the behavior gets even more unpredictable.
To simulate both read_until_idle and changing addresses, I provide the read-until-idle and change-destination features in the sample project. The default featureset just proves that the peripheral reads and writes work properly when using the standard read function.
This seems heavily related to #3900, except the leading values are zeroes instead of previous data.