[STM32F7] What could be a reason that HAL_UART_Receive_IT does not return?

[GSpre.1]

The corresponding UART works fine with HAL_UART_Receive. I've confirmed with GDB that this function fails to return. I realize I'm leaving out a lot of details here, but from the documentation I can see a lot of reasons why this function can *fail*, and a lot of ways one can screw up the handling of the interrupts, but I fail to understand how the function could just block and not return.

Any hints?

[TDK]

Could be an ISR starving it of resources. Easy enough to debug and check what's going on.

[GSpre.1]

Thanks! Do you have any hints as to how I might want to proceed? I believe the only interrupt I'm dealing with is a tick timer, as set up automatically by the CubeMX code generator.

[TDK]

Run the code in debug mode. Hit pause, see where the cpu is at.

[waclawek.jan]

Single-step in disasm.

JW

[GSpre.1]

I'm guessing this is now quite off-topic, but am I supposed to be able to `stepi` with GDB over st-link? Every time I try, the code just seems to run until I hit HAL_UART_Receive_IT (which is definitely a little while into the program), and then hang.

[Piranha]

Most likely the problem is something else. For example wrong flash latency, voltage scale, overdrive mode, clock frequency.

P.S.

huart->RxISR = NULL;
 
 /* Computation of UART mask to apply to RDR register */
 UART_MASK_COMPUTATION(huart);
 
...
 
 /* Set the Rx ISR function pointer according to the data word length */
 if ((huart->Init.WordLength == UART_WORDLENGTH_9B) && (huart->Init.Parity == UART_PARITY_NONE))
 {
 huart->RxISR = UART_RxISR_16BIT;
 }
 else
 {
 huart->RxISR = UART_RxISR_8BIT;
 }

Although the configuration itself is changed only at initialization, all of this junk is done at every transaction...

[GSpre.1]

Ugh, yeah, I keep hearing horror stories of the HAL. Do you happen to know of a good, introductory-level example of doing UART communication without using the HAL?