I agree with Chris Stratton that their is an impossibly large amount of logging.
Also the code appears to block itself with an infinite while(1) {}
loop:
while (1) {
uint8_t recvChar;
if (HAL_UART_Receive(&Device_UART_Handle, &recvChar, 1, 5000) != HAL_OK) {
printf(" Recv fail\r\n");
printf(" RXNE: %d ORE: %d NE: %d FE: %d PE: %d\r\n",
__HAL_UART_GET_FLAG(&Device_UART_Handle, UART_FLAG_RXNE),
__HAL_UART_GET_FLAG(&Device_UART_Handle, UART_FLAG_ORE),
__HAL_UART_GET_FLAG(&Device_UART_Handle, UART_FLAG_NE),
__HAL_UART_GET_FLAG(&Device_UART_Handle, UART_FLAG_FE),
__HAL_UART_GET_FLAG(&Device_UART_Handle, UART_FLAG_PE));
while(1) {} // <================= block everything forever?
}
printf(" Recv %d\r\n", recvChar);
}
when it gets an error.
Is that what you meant to happen? If this triggers, due to the logging taking too long, it's stuck forever.
Edit: (from my comment):
Ff you have control of the code at both ends of the UART connection (STM32 and ESP8266), then implement a protocol which ensures their are no lost bytes.
For example, send an acknowledge on each received byte. This would make it more complex, but also make it robust while using debug statements.
This looks like a classic "Heisenberg effect", where their are time sensitive processes, but observing them introduces hard to define delays.
An alternative approach to the logging printfs, which would be much quicker and so have less impact, would be to switch LEDs on when an errors are detected, and when a valid transmission is detected.