Hard fault after enabling interrupts in loaded application

[franti_ekkaftan]

Hi all,

I am writing a custom bootloader for the FRDM-K64F.

Up to now I've solved all problems, the loader is running fine and flashing the application OK (flash image correct, CRC for app correct etc.).

So it is almost finished but the last step seems to be always the hardest, as we are stuck on this last issue:

When jumping to application Hard fault is called after first interrupt is called.

All the interrupt stuff seems to be correct (application vector table is on correct place, all vectors initialized, SCB-VTOR pointing correctly, only FLASH vector table used).

This is the stack trace from KDS, running bootloader which just called the downloaded application:

freescale_k64f_Debug_OpenOCD [GDB OpenOCD Debugging] 

    freescale_k64f_bootloader.elf 

        Thread #1 (Suspended : Step) 

            0x10172 

            <signal handler called>() at 0xfffffff1 

            <signal handler called>() at 0xfffffff9 

            0x1085e 

            __isr_vector() at 0x100 

            __isr_vector() at 0x100 

    openocd 

    arm-none-eabi-gdb 

The exception comes when the first interrupt comes, after "cpsie i" instruction is called in the application.

The source of the interrupt should be the low power timer, which is configured in the application, and the IABR register corresponds with it:

IABR    uint32_t [8]    0xe000e300 

    IABR[0]    uint32_t    0x0 

    IABR[1]    uint32_t    0x4000000 

    IABR[2]    uint32_t    0x0 

    IABR[3]    uint32_t    0x0 

    IABR[4]    uint32_t    0x0 

    IABR[5]    uint32_t    0x0 

    IABR[6]    uint32_t    0x0 

    IABR[7]    uint32_t    0x0 

Core registers at entering the hard fault handler:

General Registers    General Purpose and FPU Register Group 

    r0    0x400ff100 

    r1    0x4000000 

    r2    0x0 

    r3    0x41a 

    r4    0x0 

    r5    0x0 

    r6    0x0 

    r7    0x2002fff8 

    r8    0x0 

    r9    0x0 

    r10    0x20020000 

    r11    0x0 

    r12    0x100 

    sp    0x2002ffb8 

    lr    0xfffffff1 

    pc    0x10170 

    xPSR    0x1000003 

    msp    0x2002ffb8 

    psp    0x0 

    primask    0x0 

    basepri    0x0 

    faultmask    0x0 

    control    0x0 

When interrupts stay disabled in the application then the application runs normally (except for the interrupt-related stuff).

EDIT: This is the SCB register block:

SCB    SCB_Type *    0xe000ed00   

    CPUID    const volatile uint32_t    0x410fc241   

    ICSR    volatile uint32_t    0x44a003   

    VTOR    volatile uint32_t    0xc100

    AIRCR    volatile uint32_t    0xfa050000   

    SCR    volatile uint32_t    0x0   

    CCR    volatile uint32_t    0x200   

    SHP    uint8_t [12]    0xe000ed18   

    SHCSR    volatile uint32_t    0x0   

    CFSR    volatile uint32_t    0x20000   

    HFSR    volatile uint32_t    0x40000000   

    DFSR    volatile uint32_t    0x0   

    MMFAR    volatile uint32_t    0xe000edf8   

    BFAR    volatile uint32_t    0xe000edf8   

    AFSR    volatile uint32_t    0x0   

    PFR    const uint32_t [2]    0xe000ed40   

    DFR    const volatile uint32_t    0x100000   

    ADR    const volatile uint32_t    0x0   

    MMFR    const uint32_t [4]    0xe000ed50   

    ISAR    const uint32_t [5]    0xe000ed60   

    RESERVED0    uint32_t [5]    0xe000ed74   

    CPACR    volatile uint32_t    0xf00000   

Seems that it is the INVSTATE bit is set in CFSR and FORCED bit is set in HFSR, which means an escalated fault. But what is the cause I don't know.

Thank you for any help

[franti_ekkaftan · Accepted solution]

Finally I have found the problem.

It was the VTOR register which has to be aligned to 0x400 for K64F.

Moving VTOR from 0xC100 to 0xC000 or 0xC400 solved the problem.

[Oxolotol]

I am having a similiar problem.  But my VTOR is set to 0x00003000.  and reads as 0x00003000 in the Memory Browser.

Originally it was set to 0x00003080, which the Memory Browser displayed as 0x00003000 and but with the 1 bit displayed several bytes away. 

but moving it to even x000 (4k) boundary did fix *not* the '<signal handler called>() at 0xfffffff9. which resulted in the HardFault after CTIMER interrupts.

[ganeshramachand]

Dear Frank,

                   Even I face the same problem [ <signal handler called> () at 0xfffffff9 ] while debugging my custom boot loader code for KE02Z controller. I am using Segger's J link debugger and working on KDS2.0. What should I do to fix the error ?

Thanks