0
\$\begingroup\$

I stopped in the middle of debugging a very simple project where I send "hello world\r\n" every couple seconds out of USART2. The first print hits the console and then I hang in an infinite loop after in startup_stm32.s:

/**
 * @brief  This is the code that gets called when the processor receives an
 *         unexpected interrupt.  This simply enters an infinite loop, preserving
 *         the system state for examination by a debugger.
 *
 * @param  None
 * @retval : None
*/
    .section .text.Default_Handler,"ax",%progbits
Default_Handler:
Infinite_Loop:
  b Infinite_Loop

I appear to not be handling an interrupt, but I myself actually have not enabled any interrupts. I am only using the HAL_UART_* API (HAL_UART_Init, HAL_UART_Transmit, and implemented the HAL_UART_ErrorCallback).

How can I learn more about what interrupt isn't being handled?

\$\endgroup\$
  • 1
    \$\begingroup\$ Presumably by examining the state of the system with a debugger \$\endgroup\$ – uglyoldbob Apr 17 at 18:48
  • 2
    \$\begingroup\$ Do you have a debugger connected? Check the NVIC registers (ISERx, ISPRx) to see which interrupts are enabled & pending. \$\endgroup\$ – brhans Apr 17 at 18:49
  • \$\begingroup\$ Assuming hardfault has a different handler, what interrupts have you enabled? \$\endgroup\$ – Chris Stratton Apr 17 at 18:56
  • 1
    \$\begingroup\$ You may be experiencing a hard fault and not even know it. electronics.stackexchange.com/a/432309/81178 \$\endgroup\$ – filo Apr 17 at 18:59
  • \$\begingroup\$ Updated with more info. I have not enabled any interrupts myself. I am just using the HAL_UART API in a way that worked on a Nucleo board but not a custom board. The working code has not changed. There's seems to be something different between the Nucleo board and mine (STM32F302R8 vs STM32F302C8YX). My goal is to generally understand what registers/etc to consider in general, to help others who hit that infinite loop. \$\endgroup\$ – tarabyte Apr 17 at 19:06
0
\$\begingroup\$

You can add a new handler with an infinite loop one at a time until the missing IRQ handler is detected. It's a slow, but reliable method. You can find the full list of weak IRQ definitions in the startup_stm32.s file.

Example incremental IRQ handler addition to stm32f3xx_it.c:

void DMA1_CH1_IRQHandler(void) {
  while (1);
}

In general, this seems to be an issue of unknown defaults. Starting a project with all the IRQ handlers implemented is one way to make sure you're not bitten.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.