2023-08-09 08:52 AM
Hello, I am using the NUCLE-F103RB and the STM32CubeIDE for developing and testing code. After my latest code change the program does not return form the below call of HAL_TIM_Base_Start_IT(&htim3).
"TEST1" is printed to the terminal, but "TEST2" is not.
Not sure if this is related, but during uploading to the NUCLEO the cursor stops is in the file sysmem.c at
void *_sbrk(ptrdiff_t incr)
This is the code where the program 'hangs'...
sprintf(msgString, "TEST1\r\n");
HAL_UART_Transmit(&huart2, (uint8_t*)msgString, strlen(msgString) , 0xFF);
/* Start the TIM Base generation in interrupt mode */
if (HAL_TIM_Base_Start_IT(&htim3) != HAL_OK) {
Error_Handler();
}
sprintf(msgString, "TEST2\r\n");
HAL_UART_Transmit(&huart2, (uint8_t*)msgString, strlen(msgString) , 0xFF);
Can this issue be related to memory management? Thank you!
Solved! Go to Solution.
2023-08-09 09:28 AM
Your timer triggers interrupts so fast that the CPU can't make any progress. Or your interrupt handler is very slow or never returns.
Slow down the timer, check your interrupt handler.
Run the debugger and hit pause when it's stuck to find out where the CPU is at.
2023-08-09 08:57 AM
Starts the interrupt, but is the interrupt being handled?
2023-08-09 08:59 AM
I don't know if it can help in your case, but I found these videos about advanced debugging:
STM32CubeIDE Advanced Debug Features
https://youtube.com/playlist?list=PLnMKNibPkDnEDEsV7IBXNvg7oNn3MfRd6
2023-08-09 09:28 AM
Your timer triggers interrupts so fast that the CPU can't make any progress. Or your interrupt handler is very slow or never returns.
Slow down the timer, check your interrupt handler.
Run the debugger and hit pause when it's stuck to find out where the CPU is at.
2023-08-09 10:42 PM
Thank you, TDK! You are correct: the callback function was too busy. I fixed it.
2023-08-09 10:48 PM
Dear RhSilicon, thank you for your response! Yes, the interrupt is being handled, but it turns out that the callback function was too busy.