После вызова любой из неблокирующих функций
HAL_UART_Transmit_IT()
HAL_UART_Receive_IT()
или 
HAL_UART_Transmit_DMA()
HAL_UART_Receive_DMA()
в нормальном (не циркуляционном) режиме

обязательно дождаться пока она отработает, в качестве признака завершения хорошо подходит вызов соответствующих функций
HAL_UART_TxCpltCallback()
HAL_UART_RxCpltCallback()

повторный вызов чтения или записи без корректного завершения предыдущего - гарантированный глюк с непонятным состоянием порта -

HAL_UART_GetState() не возвращает ничего, хотя должна бы вернуть что то из:
HAL_UART_STATE_RESET
HAL_UART_STATE_READY
HAL_UART_STATE_BUSY
HAL_UART_STATE_BUSY_TX
HAL_UART_STATE_BUSY_RX
HAL_UART_STATE_BUSY_TX_RX
HAL_UART_STATE_TIMEOUT
HAL_UART_STATE_ERROR
(самое интересное что внутри вызовов передачи\приёма анализ состояния идет именно по этой функции, но любые не\корректные состояния ведут к возврату всего трёх состояний HAL_OK, HAL_BUSY, HAL_ERROR и чтобы что то понять всёравно надо вызывать статус..., вынос мозга...)

В принципе функционала достаточно для  организации стабильной и относительно надёжной работы, но чёрт побери, хотелось бы заглянуть в скворечник человека который придумал такую идеологию работы HAL, причём похоже что аппаратный флажок занятости железки IDLE вообще игнорируется...
То что пишется на SPL в пять совершенно нечитаемых строк, на HAL занимает полный лист по идее хорошо читаемых строк, но смысл теряется в дебрях флажков\условий\и т.п. костылей...