STM32F1 HAL_UARTEx_ReceiveToIdle_DMA() can block after noise errors

[skidadddytn]

Hey everyone!

In our app we use HAL_UARTEx_ReceiveToIdle_DMA() to capture serial data to a circular buffer (same as ST Sample 'UART_ReceptionToIdle_CircularDMA UART).   It works really well until someone plugs or unplugs cables generating noise on the UART.   In this case, we just poll HAL_UART_GetError(), reset the uart using HAL_UART_Init(), and finally call HAL_UARTEx_ReceiveToIdle_DMA() again to recover.

The errors returned could be noise, parity, or framing errors (we've seen all 3).  The recovery works 95% of the time.  But, 5% of the time, after resetting the uart with HAL_UART_Init(), we will enter HAL_UARTEx_ReceiveToIdle_DMA() and it will permanently block/never return. 

We mitigated this condition by inserting a 50ms delay in between HAL_UART_Init() and HAL_UARTEx_ReceiveToIdle_DMA().    I don't feel super good about this and would rather be checking a flag but I have no idea what condition is causing HAL_UARTEx_ReceiveToIdle_DMA() to block.   I cannot get the issue (which has a 5% chance of happening)  to occur with a DEBUG build because of added debug bulk serving as a delay and possibly fixing the issue.  This makes the exact problem hard to debug.

Anyone ever seen this case?

[Karl Yamashita]

Have you tried calling HAL_UART_DeInit before you call HAL_UART_Init? 

[skidadddytn · Accepted solution]

I have not tried HAL_UART_DeInit(), thats a good idea!  

I removed the delay and replaced HAL_UART_Init() with a DeInit/Init pair.  It has not locked up yet.  I'm going to be putting it through some more testing as this problem is sort of elusive in that it does not happen all the time.

This is possibly the solution.