Unhandled exception - how to debug

[elagil]

Hello,

I am facing an unhandled exception in ChibiOS 19.1.2 and I am not sure how to proceed with debugging. I use an STM32F746.

It looks like exception "VectorF8" is called, which translates to "STM32_TIM8_CC_HANDLER". I am not actively using TIM8, as you can see from my "mcuconf.h":

Code: Select all

#define STM32_GPT_USE_TIM8                  FALSE
#define STM32_ICU_USE_TIM8                  FALSE
#define STM32_PWM_USE_TIM8                  FALSE


Is this timer used somewhere else internally? I use Lwip and wolfSSL as extensions of ChibiOS. Also, I use Timer 1 in input capture mode, but I do not see how this is related.

If more information is required, please tell me where to look.

Thanks in advance!

[Giovanni]

Is that vector shared among multiple timers? it happens a lot.

Giovanni

[elagil]

It does not look like it. Assuming that the stm32_registry.h you provide is accurate, no other peripheral uses this vector. Do you know, where the vectors are documented in ST documents? I did not find them in the reference manual, programming manual, or datasheet.

When looking at the TIM8 registers, they are all at default (zeros).

[Giovanni]

It is the STM32 RM, the vector is not shared, just checked.

Look at the map file to see which module defines that vector.

Giovanni

[elagil]

I am clueless, F8 does not seem to be initialized from any module.

Code: Select all

...
VectorF4                                          /tmp/ccbKjU1L.ltrans0.ltrans.o
                                                  ./build/obj/hal_gpt_lld.o (symbol from plugin)
                                                  ./build/obj/vectors.o
VectorF8                                          ./build/obj/vectors.o
VectorFC                                          /tmp/ccbKjU1L.ltrans0.ltrans.o
                                                  ./build/obj/stm32_dma.o (symbol from plugin)
                                                  ./build/obj/vectors.o
...                                 


Maybe I am interpreting my debugger incorrectly, but this is the call stack:

Code: Select all

_unhandled_exception@0x00209952 (./STM32F7_ChibiOS_19_Application/source/dbg/dbg.c:4)
VectorF8@0x002002de (./ChibiOS_19.1.2/os/common/startup/ARMCMx/compilers/GCC/vectors.S:1021)


I defined:

Code: Select all

void _unhandled_exception(void) {
  chSysHalt("UNDEFINED IRQ");
}


if you are wondering. It does not help much, though.

[steved]

I ended up defining some individual exception handlers in a similar situation, so that I could be confident of which vector was being triggered.
(In my case I think it was due to a difference in how some feature was handled across Chibi versions, but might have misremembered that. Could have been a stack overflow)

[rew]

Two suggestions:

First: All of the unhandled exceptions share the same code: "somthing bad happened, stop the system". Those share the same physical code in the flash memory, so when the processor stops there, the debugger doesn't know what triggered it, it looks up the program counter address and finds a bunch of symbols at that address. Then it takes the first or last of those and prints that.

As the unhandled exception handler, I suggest that you (Giovanni too!) add some code that does something like:

Code: Select all

void unhandled_exception ()
struct unhandled_debug {
   uint32 ISR;
} dbg;

dbg.ISR = RCC.ISR;
while (1); // halt the system.
}

I just made up that "ISR" register in the RCC: Somewhere you should be able to read a register that has status about the last interrupt and why it happened. You can add registers as you go ahead. Once you stop the CPU in the while loop, you can print all the debug registers with tags with "print dbg" in gdb. (you could also do this directly with print *(uint32_t *) 0xXXyyZZ, but this is way more convenient).

For chibios to maintain the lowest possible memory footprint this would be hidden behind an ifdef DEBUG....

[Giovanni]

The CPU status register (xPSR) lower bits (8..0) contain the current exception number, you can inspect that in the debugger after halt.

Giovanni

[mikeprotts]

VectorF8 is probably not relevant, it's more likely to be out of memory or similar. You may need to reduce usage somewhere, or increase the allocation to the relevant area - at a guess PORT_INT_REQUIRED_STACK may need to be larger.

Mike

[elagil]

Thanks for the suggestions, I will investigate! Making a custom exception handler that stores registers sounds practical.

I am using a lot of dynamic threads and pool memory allocation which may cause issues. I did indeed notice broken pool element addresses in some cases, indicating memory problems. Firstly, I will migrate to a thread structure that is completely static and see if the problems go away.

it's more likely to be out of memory or similar

Since I have all chibiOS debug options enabled, would I not see some debug message? After all dynamic thread and pool element allocations, I use "chDbgAssert" and check for NULL pointers. Stack overflows would also be indicated, as far as I am aware.