Usart is not recovering from error without a delay before going to sleep

[SBrinkmann]

Hello,

we are using the usart on a STM32U5 controller. (Happens too on STM32L0 and stop mode)

The problem short summarize:

We get a rx error, disable the rx and go to sleep stop2. The usart rx never goes back to normal operation. This can be solved by a delay before going to sleep. Why?

The usart is configurated as follows:

- Usart 3 is used

- HSI16 as clock source

- Autobaud is on

- Parity off;

- DMA is used for Sending/Receiving

- Full duplex lines

- RTU used

The normal programm flow:

- The controllerA is sleeping in stop2 and rx line gpio interrupt is active.

- If any falling edge is received on RX line the controllerA wakes up by interrupt.

(In normal case the other controllerB will send a short "breaksignal" to wake up the controllerA.) 

(The controllerA is not in listen mode in the normal case. (Usart RX disabled))

- If controllerA is woken up by interrupt, it will disable gpio interrupt for rx line and configure their usart as follows:

- All "old" usarts interrupts states are cleared

- Receiving is activated

- DMA for receiving is activated

- RTU is activated 

- Usart interrupts are activated

- In normal case the RTU timeout occurs and the valid data are in the buffer. 

- DMA is turned off

- The usart interrupts are turned off

- The usart receiver is turned off

- The received data are parsed. 

- The rx line gpio interrupt is turned on again

- Controller will now enter sleep stop2 again.

The failure programm flow:

The problem occurs if the rx line is to long on low level and the controllerA is receiving this state. 

(This can happen if the controllerB is resetting or was unplugged.)

The program flow described above is valid in this case too. 

The DMA receiving will return with no/zero data received in this case. So we can recognize this case fine. 

Our expection is that after receiving the broken data and the rx line is stable again the controllerA/usart is happy again 

and the normal state flow will be valid in next receiving

But the usart is hold in the state that it is not receiving valid data anymore and never again. 

Except we do a breakpoint or magic delay about 10ms before we are going back to sleep stop2.

So we are pretty sure, there is some racing condition and the usart is not ready to go to sleep.

But we honestly have no idea what state of usart have to be polled or what bit we have to wait for. 

This pictures show the state in failure at the point received data should be parsed.