Going into hard fault handler when missing interrupt

[keyur]

Posted on December 24, 2015 at 10:49

Hello

I have configured the board for the rising edge interrupt but the slave does not support it. It requires host GPIO to be configured in active high level trigger mode. Because of this some times I am missing the interrupt and that is causing the code to go into hard fault handler. I have added a code to the hard fault handler as per the suggestion in forum. HardFault_Handler\                PROC                    ; EXPORT  HardFault_HandlerC          [WEAK]                  IMPORT  HardFault_HandlerC                  TST LR, #4                 ITE EQ                 MRSEQ R0,MSP                 MRSNE R0,PSP                 B     HardFault_HandlerC                ENDP c code is below /**  * HardFaultHandler_C:  * This is called from the HardFault_HandlerAsm with a pointer the Fault stack  * as the parameter. We can then read the values from the stack and place them  * into local variables for ease of reading.  * We then read the various Fault Status and Address Registers to help decode  * cause of the fault.  * The function ends with a BKPT instruction to force control back into the debugger  */ void HardFault_HandlerC(unsigned long *hardfault_args){         volatile unsigned long stacked_r0 ;         volatile unsigned long stacked_r1 ;         volatile unsigned long stacked_r2 ;         volatile unsigned long stacked_r3 ;         volatile unsigned long stacked_r12 ;         volatile unsigned long stacked_lr ;         volatile unsigned long stacked_pc ;         volatile unsigned long stacked_psr ;         volatile unsigned long _CFSR ;         volatile unsigned long _HFSR ;         volatile unsigned long _DFSR ;         volatile unsigned long _AFSR ;         volatile unsigned long _BFAR ;         volatile unsigned long _MMAR ;         stacked_r0 = ((unsigned long)hardfault_args[0]) ;         stacked_r1 = ((unsigned long)hardfault_args[1]) ;         stacked_r2 = ((unsigned long)hardfault_args[2]) ;         stacked_r3 = ((unsigned long)hardfault_args[3]) ;         stacked_r12 = ((unsigned long)hardfault_args[4]) ;         stacked_lr = ((unsigned long)hardfault_args[5]) ;         stacked_pc = ((unsigned long)hardfault_args[6]) ;         stacked_psr = ((unsigned long)hardfault_args[7]) ;         // Configurable Fault Status Register         // Consists of MMSR, BFSR and UFSR         _CFSR = (*((volatile unsigned long *)(0xE000ED28))) ;                                                                                                     // Hard Fault Status Register         _HFSR = (*((volatile unsigned long *)(0xE000ED2C))) ;         // Debug Fault Status Register         _DFSR = (*((volatile unsigned long *)(0xE000ED30))) ;         // Auxiliary Fault Status Register         _AFSR = (*((volatile unsigned long *)(0xE000ED3C))) ;         // Read the Fault Address Registers. These may not contain valid values.         // Check BFARVALID/MMARVALID to see if they are valid values         // MemManage Fault Address Register         _MMAR = (*((volatile unsigned long *)(0xE000ED34))) ;         // Bus Fault Address Register         _BFAR = (*((volatile unsigned long *)(0xE000ED38))) ;         __asm(''BKPT #0\n'') ; // Break into the debugger } When this hits the break point the register values is attached in attachments.

[Tesla DeLorean]

Posted on December 24, 2015 at 16:54

Well you'll have to review the failure within the context of your own system.

You'd want to start by identifying the assembler code immediately prior to 0x08002C92

[re.wolff9]

Posted on December 27, 2015 at 13:47

On the other hand, you can examine the contents of the fault status registers. 

The hardfault status register seems to be zero. Weird. The cfsr seems to be 0x00..00f. which seems to indicate memory access violation,  while accessing DATA AND INSTRUCTION while unstacking from an exception. In addition to this, a ''reserved'' bit is set. Saying that: I might be looking at the wrong manual: I'm looking at Cortex-M3, you haven't said what processor you have, so my guess is valid (I just googled, and google apparently liked the M3 page for this more than the M4 page).