UART not working while debugging - Custom STM32U5 LPUART1 Interrupt

[TV79]

Hello,

I'm working with an STM32U5 custom board.

I use the LPUART1 to read input with an interrupt as shown below and to write it back on the same LPUART1 :

In the while loop of the main function I have :

 

while (1)
{
 /* USER CODE END WHILE */
 /* USER CODE BEGIN 3 */
 HAL_GPIO_TogglePin (GPIOA, GPIO_PIN_11);
 HAL_UART_Transmit(&hlpuart1, (uint8_t *)aRxBuffer, sizeof(aRxBuffer), 10);
 HAL_Delay (1000); /* Insert delay 100 ms */
}

 

And I've also created the function below:

 

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
 HAL_GPIO_TogglePin (GPIOA, GPIO_PIN_8);
 HAL_UART_Receive_IT(huart, (uint8_t *)aRxBuffer, 10);
}

 

 

And this work fine but only if don't execute the code with the debbuger. If I execute the code with the debugger, nothing is never printed and the interrupt is never executed.

I've tried this with STM32CubeIde debugger and same problem with STM32 extension in VSCode with Cortex-Debug.

 

[Bob S]

When using the debugger do you have the UART registers displayed in the SFR window?  If so, don't do that as it messes with the status/interrupt bits.

That said, the transmit in your main loop is using the same buffer as you receive, and the first time through the loop that buffer contains WHAT?  You don't show your code before the while() loop (and please use the "code tags" button when posting code, it looks like "</>").

Running with the debugger starts the CPU differently than free-running from a power-on reset.  The debugger skips reading the start vector and stack address from the interrupt table and starts execution at what it thinks is the starting point of the program.  Usually a minor point and usually causes "runs under debugger but not from power on" issues if you move the vector table.  Apparently not the issue you have.

[TV79]

Hello @Bob S thanks for your answer, that's interesting.

I don't have the UART register displayed in the SFR window so it's not the reason.

My buffer is an uninitialized uint8_t array (OK that's bad but it should be all zero).

Well apparently the problem is coming from the FT230XQ-R FTDI module connected to my UART. Now If I use another device on another UART it works as expected.

Best regards.

[Tesla DeLorean]

Perhaps IO levels?

Get a scope on it.

Perhaps improve the code so it doesn't just send the buffer every second, regardless if it fills or not. Perhaps also count and output the number of times the Interrupt/Callback was called.

Would need 10 interrupts / callback. Check also status of UART, for errors, or error returns from the functions.