Linker prolem with bootloader

Asked by Fred Diete on 2017-03-14


I have to build an application that will be in the flash memory with a custom bootloader (no source available, but is built with Keil).
The bootloader resides @0x8000000 and after performing some operations, will jump to a specific address (0x8030000).

I thought to move the application start address to 0x8030000, so I followed this steps (in main.c file):

1) HAL_Init();
2) SystemClock_Config()
3) Interrupt Vector remap (I copy g_pfnVectors into a variable, disable irq, make SCB->VTOR poit to the variable, re-enable irq)
4) SystemCoreClockUpdate()

The linker script I used looks like this:

bootloader (rx) : ORIGIN = 0x08000000, LENGTH = 192K
flash (rx) : ORIGIN = 0x08030000, LENGTH = 2048K - 192K
ram (rwx) : ORIGIN = 0x20000000, LENGTH = 192K

while the sections like this:

.bootloader :
. = ALIGN(4);
. = ALIGN(4);
} >bootloader

/* Reset and ISR vectors */
.isr_vector :
isr_vector_start = .;
} >flash


However when the binary is loaded, it meets an hard fault and it does not start.
The generation of the elf file is successful and the map file seems correct (also using objdump).

Am I doing something wrong? Could you please help me?

I'm building the application with Eclipse + SW4STM32 and Ac6. The application has been created starting from source code automatically generated with STM32CubeMX for the micro - STM32F429 (with 2MB of Flash).

Thank you

Question information

English Edit question
GNU Arm Embedded Toolchain Edit question
No assignee Edit question
Last query:
Last reply:

Hi Fred,

Using a debugger can you see where does the fault occur?

Best regards.

Fred Diete (f429l) said : #2

Hello Thomas,

thank you for your interest.

Unfortunately no. I cannot debug the bootloader because the source is not open. I have only .hex file that I load into the flash memory, with openOCD, at address 0x08000000.
Instead, the application (the one I develop with eclipse) is loaded with a software (also custom and closed) that allows me to specify the address in the flash where the application is copied.

I checked with ST-Link Utility and there is no overlapping between the two binaries (bootloader and application).
The generation of the .elf file is successful and the map file seems correct (also using objdump).

Also, is correct the procedure that I use (linker script and edits in main.c file) in order to change the start address of the application?

Hi Fred,

Even with closed source you can probably see the instructions on which the fault occurs (disassemble would show it for instance). The procedure you use looks alright to me but I might be missing something.

Best regards.

Fred Diete (f429l) said : #4

Ok, thank you.

Could you please tell me how I can disassemble it?
I mean, also objdumb would be a solution, however how can I follow step-by-step the execution to see where the fault occurs?

thank you and my best regards.

stepi and nexti are instruction level equivalent to step and next.

Launchpad Janitor (janitor) said : #6

This question was expired because it remained in the 'Needs information' state without activity for the last 15 days.