Skip to main content
Mrunal A
Associate III
February 23, 2018
Solved

Jumping to stored code triggers hardfault interrupt!

  • February 23, 2018
  • 3 replies
  • 2696 views
Posted on February 23, 2018 at 07:04

Hello,

I have developed a IAP application based on STM32F030CCT6. The application code is received on UART and I can store it in flash, I am storing codeat 0x08010000. But I am facing problems in executing it. While trying to jump at code my code goes into HardFault interrupt. And unfortunately on this MCU there is no implementation of HFSR and VTOR. Hence I am not getting the reason for hardfault! I am using below code for jumping. And I have also remapped the Vector table in application binary. I am using Keil MDK5 and hence I have verified the addresses of code from MAP file. The application code's RESET starts at

0x08010000. and the IAP starts at0x08000000 as expected. Please guide me.

typedef void (*jumpFunction) (void);//typedef for function pointer jumpFunction JumpToFunction;

//Function pointer uint32_t JumpAddress,somaddr;//Address of function pointer

__disable_irq(); JumpAddress = *(__IO uint32_t*)(FLASH_X_START_ADDR + 4);

JumpToFunction = (jumpFunction) JumpAddress; /* Initialize user application's Stack Pointer */

__set_MSP(*(__IO uint32_t*) FLASH_X_START_ADDR); /* Jump to application */

JumpToFunction();

#stm32f0-iap-multi-app

Note: this post was migrated and contained many threaded conversations, some content may be missing.
    This topic has been closed for replies.
    Best answer by Mrunal A
    Posted on February 26, 2018 at 10:39

    I got it working! The binary was correct, but I was writing the binary in wrong order, and hence while execution Hardfault interrupt is certain! I found this fault because of

    Waclawek.Jan

    comment regarding what should be in the flash after writing binary. And I examined the binary and stored flash and found it was different, after some study I found the bug was in writing the binary. I hope this will help some body in future.

    3 replies

    waclawek.jan
    Super User
    February 23, 2018
    Posted on February 23, 2018 at 07:18

    And unfortunately on this MCU there is no implementation of HFSR and VTOR.

    This is why you need to keep the vector table in RAM, which is remapped to 0x0000'0000. This has been discussed here (e.g.

    ), try searching.

    JW

    Mrunal A
    Mrunal AAuthor
    Associate III
    February 23, 2018
    Posted on February 23, 2018 at 07:20

    Yes I did it. I remapped my Vector Table in RAM.

    waclawek.jan
    Super User
    February 23, 2018
    Posted on February 23, 2018 at 07:22

    How?

    And what exactly triggers the fault?

    JW

    Tesla DeLorean
    Guru
    February 23, 2018
    Posted on February 23, 2018 at 07:23

    Slowly step the code observing the point at which it goes to the Hard Fault Handler, and the registers in this case.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Mrunal A
    Mrunal AAuthor
    Associate III
    February 23, 2018
    Posted on February 23, 2018 at 07:32

    I done this, but it directly jumps to hard fault interrupt after calling 'jumpToFunction()' . Hence I am not able to see detailed call stack. By the way I am curious about the code I am using. Its provided in example code of IAP. The MSP is set to 0x102D0020 and the 'jumpAddress' is 0x2D0020CD but I guess it should be 0x08010004 isn't it? So I think this is making problem. Please correct me if I am wrong.

    Tesla DeLorean
    Guru
    February 23, 2018
    Posted on February 23, 2018 at 07:44

    The jump address won't be 0x08010004, it should be loading the value FROM that address, and it should point to the Reset Handler on you app.

    The numbers you are quoting don't seem to be valid. You should double check the front of you app image for the vector table.

    The processor will fault if you try to jump to an invalid address, or the stack is invalid.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Mrunal A
    Mrunal AAuthorBest answer
    Associate III
    February 26, 2018
    Posted on February 26, 2018 at 10:39

    I got it working! The binary was correct, but I was writing the binary in wrong order, and hence while execution Hardfault interrupt is certain! I found this fault because of

    Waclawek.Jan

    comment regarding what should be in the flash after writing binary. And I examined the binary and stored flash and found it was different, after some study I found the bug was in writing the binary. I hope this will help some body in future.