UART_IT_IDLE interrupt unhandled

[cutephoton]

I checked both STM32f4/7's HAL driver implementation. It appears the interrupt for the IDLE status is not handled by the HAL's interrupt handler. My review was not extensive, but I believe this to be the case.
During initialization, the driver sometimes comes up with the IDLE flag set and never recovers because the flag is never cleared.

Anybody who encounter this case can disable the interrupt by commenting out...

__HAL_UART_ENABLE_IT(huart_, UART_IT_IDLE);

I think this flag is mostly used in half duplex use cases? Not sure.

[lixpaulian]

You did overlook the essential. The use of the IDLE interrupt is the core of this driver. This is in fact the most desirable way to finish a DMA transfer. Indeed, the interrupt on idle is not handled currently by HAL, but if you check again the readme, you will notice that I explain how to handle it using several lines of "user code" in HAL, see below:

/* USER CODE BEGIN USART6_IRQn 1 */
if (__HAL_UART_GET_FLAG (&huart6, UART_FLAG_IDLE))
{
	__HAL_UART_CLEAR_IDLEFLAG (&huart6);
	HAL_UART_RxCpltCallback (&huart6);
}
/* USER CODE END USART6_IRQn 1 */

This is the point of the driver, as when using DMA on receive, most of the time the application doesn't know how many characters it expects. So disabling this interrupt effectively "kills" the driver when in DMA mode.

[cutephoton]

Sorry - You're right. My integration was incomplete -- guess I figured I had finished the job after the build issues were resolved. Thanks for clarifying. Also helpful because I had approached that problem previously by using a timer in the past. But sigh -- I sometimes wonder why ST leaves this stuff out -- these are pretty simple useful improvements.

I agree the driver works well per the other issue. :)

[lixpaulian]

Just out of curiosity, do you use the driver with uOS++, or you did adapt it to another RTOS?