HardFault Interrupt

[maksim_lipskiy]

Hello! I  use FRDM-K64F board.

An interrupt "HardFault_IRQn" occurs when used uart.

How to understand, because of what occurs this interrupt and fix error?

Thanks

[Robin_Shen]

Hi Maksim,

You can refer the method in Debugging ARM Cortex-M Hard Faults with GDB Custom Command.

Hope that help.

Best Regards,

Robin

[egoodii]

Add a hard-fault handler that gives details to you about the event.

[mjbcswitzerland]

Hi

Most hard faults when accessing peripherals are due to the fact that the clock to the peripheral has not been enabled.

Check that the UART's clock is gated in the corresponding SIM_SCGCx register.

Regards

Mark

[maksim_lipskiy]

Thank You Mark!
I check SIM_SCGC1 register (because i'm use UART4) in  HardFault handler. 
UART4 Clock Enable  SIM_SCGC1 = 0x00000400;

[mjbcswitzerland]

Hi

That means that the UART4 is being clocked and the hard fault must be due to another reason than a UART peripheral access.

I find the following easily identifies such problems:

1. Use a hard fault handler that doesn't do anything - just returns

2. Set a break point in the hard fault handler (or with disabled watchdog just pause the debugger when it is firing).

3. Using disassemble mode, single step out of the hard fault handler. This will return to the instruction that causes the fault and if you step further it will repeat the error and go back into the fault handler.
Usually it is obvîous what is wrong when the bad instruction is seen.

Regards

Mark

For FRDM-K64F see: http://www.utasker.com/kinetis/FRDM-K64F.html

[maksim_lipskiy]

If that's what happened to step out of the Hardfault interrupt handler:

[mjbcswitzerland]

Hi

If this is accurate, it is showing that the hard fault is due to your code trying to run in the memory area 0x79aff020, which is invalid. Why the code is trying to run from there will be due to a problem such as using a bad pointer to jump to, trying to handle an interrupt which has an invalid/random interrupt vector or returnîng from a sub-routine where the stack has been corrupted (and the return address overwritten with random data).

You will need to study your code to work out where the failure start from (if the error is consistent you can simply step through the normal operation until it fails) or use proven code to save needing to do such excercises.

Regards

Mark

[maksim_lipskiy]

Thank you very much for your answer. I
I set a slight delay after the function sending data for UART and  hardfault inerrupt ceased !!!

[maksim_lipskiy]

Thank you.
Now I will test.