STM32 – Applications Hardfault After Jumping from the Bootloader

armbootloadercmicrocontrollerstm32

I am attempting to write a custom bootloader for a STM32F103C8Tx (64k Flash, 20k RAM variant) on a bluepill board.

When the jump from the bootloader occurs the application immediately hardfaults on the next step from the entry point of the application.

I can confirm that SCB->VTOR is set to 0x08005000. If I single step the bootloader it does jump to address 0x8005004.

Here is the stack trace at the jump.

The next step resulting in the hardfault.

Note the call to address 0xfffffffe witch (I believe) is out of scope of the memory map. I have no idea how to debug this.

Edit: I found the exact instruction where the hardfault occurs in the GDB output. 0x08005014

08005000: 00 50         str     r0, [r0, r0]
08005002: 00 20         movs    r0, #0
08005004: 35 54         strb    r5, [r6, r0]
08005006: 00 08         lsrs    r0, r0, #32
08005008: c9 53         strh    r1, [r1, r7]
0800500a: 00 08         lsrs    r0, r0, #32
0800500c: cf 53         strh    r7, [r1, r7]
0800500e: 00 08         lsrs    r0, r0, #32
08005010: d7 53         strh    r7, [r2, r7]
08005012: 00 08         lsrs    r0, r0, #32
08005014: dd 53         strh    r5, [r3, r7]

Something I have noticed is that when I run the application from debug or Terminate and Relaunch, the application runs fine with no problem while the bootloader is in flash.
If I reset the MCU or the bootloader is not in flash, I get the hardfault.

Additional context

Both BOOT pins are set to 0 to set it to boot from the main flash memory.

The bootloader is placed at 0x8000000 and the application is placed at 0x8005000.

Bootloader linker script:

MEMORY
{
  RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = 20K
  FLASH    (rx)    : ORIGIN = 0x8000000,   LENGTH = 19K
}

Application linker script:

MEMORY
{
  RAM    (xrw)     : ORIGIN = 0x20000000,   LENGTH = 20K
  FLASH    (rx)    : ORIGIN = 0x8005000,   LENGTH = 36K
}

The application vector table is set as follows:

#define VECT_TAB_OFFSET         0x00005000U

Note: I have written the bootloader in C++ and not C, so there is some name mangling from the map file.

I have modified the startup_xxx.s file to immediately call the bootloader jump. This is to avoid de-initializing any peripherals or interrupts that may interfere with the application.

LoopFillZerobss:
  cmp r2, r4
  bcc FillZerobss

    bl _Z6blCallv
/* Call the clock system intitialization function.*/

Call the jump to the application

void blCall(void){
    typedef void (*jump_app)(void);

    uint32_t _jump = (uint32_t) (__IO uint32_t*)0x08005000;
    jump_app app_jump = (jump_app) (_jump + 4);

    SCB->VTOR = _jump;
    __set_MSP(_jump);
    app_jump();
}

I also tried this with the same result as per @Justme's suggestion.

void blCall(void){
    typedef void (*jump_app)(void);
    uint32_t _jump = (uint32_t) (__IO uint32_t*)0x08005000;
    jump_app app_jump = (jump_app) (_jump + 4);

    SCB->VTOR = _jump;
    __set_MSP(_jump + 4);
    app_jump();
}

Switched from C++ to C with no change in the result.

The application is nothing special. It is basically a default generated CubeIDE main with the external HSE set and some GPIO pins for LEDs. The application runs fine if I remove the vector table offset.

IDE: STM32CubeIDE V1.9.0

Debugger: Segger J-Link EDU

Best Answer

it does jump to address 0x8005004

This is the source of your problem - you're trying to jump to 0x08005004. That address does not contain any code - it contains the address of your reset handler (0x08005435).
Same with all the other data following on at 0x08005008, 0x0800500c, etc - those are the addresses of the interrupts handlers at 0x080053c9, 0x080053cf, etc.
You'll notice that these are all odd numbers (with the LSB set) to tell the core that it must execute the instructions there in THUMB mode (with 16-bit wide instructions) rather than ARM mode (with 32-bit wide instructions) - this is normal - your reset handler is actually at 0x08005434.

So you need to declare your _jump as a pointer (not an integer) and dereference it in order to jump to the location it points to.
I'd expect something like this to work (and I've renamed your _jump to _vectable):

void blCall(void)
{
    typedef void (*jump_app)(void);

    uint32_t *_vectable = (__IO uint32_t*)0x08005000;  // point _vectable to the start of the application at 0x08005000

    jump_app app_jump = (jump_app) *(_vectable + 1);   // get the address of the application's reset handler by loading the 2nd entry in the table

    SCB->VTOR = _vectable;   // point VTOR to the start of the application's vector table

    __set_MSP(*_vectable);   // setup the initial stack pointer using the RAM address contained at the start of the vector table

    app_jump();   // call the application's reset handler
}

Note that I'm doing _vectable + 1, because _vectable is a pointer to a uint32_t, which has a size of 4 already, and then I'm dereferencing the result so that I load the value at 0x08005004 (0x08005435), rather than 0x08005004 itself.

Similarly when setting the MSP, I dereference _vectable to load the value at 0x08005000 (0x20005000).

You could also treat _vectable as an array and do something like:

void blCall(void)
{
    typedef void (*jump_app)(void);

    uint32_t *_vectable = (__IO uint32_t*)0x08005000;  // point _vectable to the start of the application at 0x08005000

    jump_app app_jump = (jump_app) _vectable[1];   // get the address of the application's reset handler by loading the 2nd entry in the table

    SCB->VTOR = _vectable;   // point VTOR to the start of the application's vector table

    __set_MSP(_vectable[0]);   // setup the initial stack pointer using the RAM address contained at the start of the vector table

    app_jump();   // call the application's reset handler
}

This code should have exactly the same effect.

Depending on your compiler, you might be able to save a tiny amount of stack space by adding a little to your jump_app typedef:
typedef void (*jump_app)(void) __attribute__((noreturn));
The attribute on the end tells the compiler that the call to that function will never return, so there's no need for it to push the return location onto the stack.

Related Solutions

Electronic – AVR simple bootloader – how to call application code

You are misunderstanding the function of the assembler command.

If you program a "GOTO" in C, the jmp assembler command comes out. It is just what it says on the tin: Jump. It tells the compiler nothing about code location.

Nowhere in your code do you specify what code goes where, as such the compiler just decides for you that you want the code to go where it thinks is best. Which most likely is the start of non-vector non-boot space.

I think you'd be well off going to: http://www.avrfreaks.net/

And searching for "[TUT] Bootloader" and see if there's a tutorial that pops up that fits your general way of thinking. It'll take you at least a good half day, but you will learn most you need to know about it.

Edit:

I forgot to point out that your code also doesn't stop at a predictable point. These days often the compiler helps out in the assumption you mean to stop at the end of main(), but it's "good manners" to include a while(1){}; at the end, where you want the code to halt. That way you are in absolute control of what happens and you are absolutely sure your code doesn't just run on into empty flash.

Electronic – bootloader application on arm controller

The way we do it in one of our products is like this (code is based on IAR compiler, so pragmas might differ for you):

We defined a structure which contains important information of the application part (which is called mainpart in our projects):

#pragma pack(push,1)
    struct softwareRevision_t {
        uint8_t VersionSystem;
        uint8_t VersionFunction;
        uint8_t VersionError;
        uint8_t VersionCustomer;
        uint8_t BuildNumber;
    };
#pragma pack(pop)

#pragma pack(push,1)
    struct mainInfoStruct_t {
        softwareRevision_t softwareRevision;
        uint32_t startFunctionAddress;
        uint8_t reserve[27];
        uint32_t bootControl;
    };
#pragma pack(pop)

This contains among other things the uint32_t startFunctionAddress. Now for this structure to be useful, you have to do several things:

Initialize it with meaningful values in the application
Make it const so it can be placed in flash
Tell the linker to place the structure always on the exact same location every time you compile your project
share the location and structure between application and boot part

In the application part:

To share the location, we created a header-file which is included in both parts with a simple define:

#define MAIN_INFO_MEMORY_POSITION (0x0807FFD4)

In a .cpp file of our application we create an instance of the structure which is placed accordingly:

#pragma location = MAIN_INFO_MEMORY_POSITION
extern __root const mainInfoStruct_t mainInfoStruct =
{
    {
            1U,     // mainInfo.softwareRevision.VersionSystem
            0U,     // mainInfo.softwareRevision.VersionFunction
            0U,     // mainInfo.softwareRevision.VersionError
            0U,     // mainInfo.softwareRevision.VersionCustomer
            0U      // mainInfo.softwareRevision.BuildNumber
    },

    reinterpret_cast<uint32_t>((&_start)),  // mainInfo.startFunctionAddress
    {0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U,0U},     // reserve

    0xF0F0FFFFU     // mainInfo.bootControl
};

Several things happen here: #pragma location = MAIN_INFO_MEMORY_POSITION tells the linker where to place the next structure.

The __root tells our linker that this symbol must be kept, even if it is not referenced by the application code (which it isn't). It has to be const otherwise it would not get placed in flash (if it doesn't end up in flash try adding a static).

So with this we have done everything in the application.

In the boot part:

The boot part needs access to the application part info structure. We wrapped a class around this whole thing, but basically a pointer will be enough:

volatile mainInfoStruct_t* pMainInfo = reinterpret_cast<mainInfoStruct_t*>(MAIN_INFO_MEMORY_POSITION);

We use volatile here to make sure, that the compiler will not optimize the access to the flash away. With this you can now jump into the application code with an ugly cast:

(reinterpret_cast<void (*)(void)>(pMainInfo->startFunctionAddress))();

Notes:

In our application we do a CRC check over the whole application part which includes the mainInfoStruct, so we don't jump into nirvana is something went wrong with the update.

The first thing we do in our application is to set the stackpointer to the value it is expected to start with (you can get that from the linker configuration file or your interrupt vector table). Otherwise you might end up with a stack overflow and corrupting your other data.

This is not a minimal example, but might give some hint on what might be useful in a shared structure as well.

We use C++, sorry for the reinterpret_casts.

Best Answer

Related Solutions

Electronic – AVR simple bootloader – how to call application code

Electronic – bootloader application on arm controller

Related Topic