2013-11-05 10:34 AM
Hello,
I'm using a STM32-discovery Board equiped with a STM32F100RB. Till now all I'm trying to do is to call the Interrupt-Handler of TIM3. But when calling NVIC_EnableIRQ(TIM2_IRQn) the programm is always running into the Hardfault_Handler.Is there anybody who knows the reason for this behaviour?thanks, Klaas.2013-11-05 11:45 AM
Till now all I'm trying to do is to call the Interrupt-Handler of TIM
3
. But when calling NVIC_EnableIRQ(TIM2
_IRQn) the programm is always running into the Hardfault_Handler.A typo ? Check that you implemented the correct handler, and enabled the matching interrupt.
2013-11-05 12:01 PM
GNU/GCC typically dumps all unhandled interrupts in the same spot, via weak linkage.
With C++ watch for name mangling of the handler routines. A Hard Fault could occur due to missing handler (naming or linkage), or the routine depending on variables/pointers you haven't properly initialized prior to enabling the interrupt.2013-11-06 03:47 AM
Here is a good article that helped me:
http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html Slightly modified code: /** * @brief C part of hard fault handler * @brief http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html * @param pointer to stack frame * @retval none * @date 2013-10-07 */ void irqGetStackFrame(uint32_t *stackframe) { StackR0 = stackframe[0]; StackR1 = stackframe[1]; StackR2 = stackframe[2]; StackR3 = stackframe[3]; StackR12 = stackframe[4]; StackLR = stackframe[5]; StackPC = stackframe[6]; StackPSR = stackframe[7]; for(;;) { } } /* irqGetStackFrame */ /** * @brief assembler part of hard fault handler * @brief http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html * @param none * @retval none * @date 2013-10-07 */ void HardFault_Handler(void) { __asm volatile ( '' tst lr, #4 \n'' '' ite eq \n'' '' mrseq r0, msp \n'' '' mrsne r0, psp \n'' '' ldr r1, [r0, #24] \n'' '' ldr r2, handler2_address_const \n'' '' bx r2 \n'' '' handler2_address_const: .word irqGetStackFrame \n'' ); } /* HardFault_Handler */ Here is what I do with undefined interrupt handlers, the number passed to the default hanler helps to find the problem: /** * @brief default IRQ handler called by spurious interrupts * @param irq: interrupt number * @retval none * @date 2013-10-04 */ static void defaultIrqHandler(int irq) { for (;;) { } } /* defaultIrqHandler */ void NMI_Handler(void) { defaultIrqHandler(-9); } void MemManage_Handler(void) { defaultIrqHandler(-7); } void BusFault_Handler(void) { defaultIrqHandler(-6); } void UsageFault_Handler(void) { defaultIrqHandler(-5); } void SVC_Handler(void) { defaultIrqHandler(-4); } void DebugMon_Handler(void) { defaultIrqHandler(-3); } void PendSV_Handler(void) { defaultIrqHandler(-2); } #if 0 //defined somewhere else void SysTick_Handler(void) { defaultIrqHandler(-1); } #endif void WWDG_IRQHandler(void) { defaultIrqHandler(0); } void PVD_IRQHandler(void) { defaultIrqHandler(1); } void TAMP_STAMP_IRQHandler(void) { defaultIrqHandler(2); } void RTC_WKUP_IRQHandler(void) { defaultIrqHandler(3); } void FLASH_IRQHandler(void) { defaultIrqHandler(4); } void RCC_IRQHandler(void) { defaultIrqHandler(5); } etc...2013-11-07 12:09 AM
Even if it's not the nicest solution I found one. I updated the CMSIS and Periph-Driver Package provided by ST from Version 3.3 to 3.4 and no it's working.
thanks for the replies anyway!2013-11-07 04:21 AM
http://www.st.com/web/en/catalog/tools/PF257890
Perhaps it relates to broader support for different chips, different interrupt vectors/implementation based on part/pre-processor defines.