cancel
Showing results for 
Search instead for 
Did you mean: 

HardFault on __libc_init_array when jumping to application after bootloader on STM32L476RG

LucasRosa
Associate II

Hello everyone,

I'm facing a HardFault issue when jumping from a bootloader to an application on the STM32L476RG.
The fault occurs right at the beginning of the application, specifically at the instruction bl __libc_init_array inside the Reset_Handler (from startup_stm32l476xx.s).

Memory layout:
Bootloader: starts at 0x08000000, size: 12 kB

Application: starts at 0x08004000, max size: 150 kB (currently using ~95%)

RAM usage: around 30%

Bootloader jump sequence:

typedef void (*p_function)(void);

static void app_start(boot_t *self) {
HAL_DeInit();
self->boot.address = *(volatile uint32_t *)(self->address.app + 4);
self->boot.jump_to_app = (p_function) self->boot.address;

__set_MSP(*(volatile uint32_t *) self->address.app);
SCB->VTOR = self->address.app;

self->boot.jump_to_app();
}
Here, self->address.app = 0x08004000.

The bootloader reads the application’s initial stack pointer and reset vector from 0x08004000 and 0x08004004, respectively, and then jumps to the reset handler of the application.

Observed behavior:
A HardFault occurs as soon as the application starts, and the CFSR register indicates IACCVIOL (Instruction Access Violation).

The faulting instruction is bl __libc_init_array inside Reset_Handler.

The application works perfectly if I start it directly via debugger.

If I comment out random application functions — even ones that are never executed — the HardFault disappears.

It feels like some flash layout, alignment, or size constraint is being silently violated.

What I've tried:
Verified that the application’s vector table and Reset_Handler are correctly located at the beginning of the application flash (0x08004000).

Increased application FLASH size in linker script from 150 kB to 200 kB → no effect.

Increased _Min_Heap_Size and _Min_Stack_Size up to 3× → no effect.

Verified that SCB->VTOR is set to the correct base address before jumping.

Any insight or help would be greatly appreciated — this issue has been very tricky to track down.

Thank you!

1 ACCEPTED SOLUTION

Accepted Solutions
LucasRosa
Associate II

Hello guys, I found out what was wrong. It turns out I was accidentally erasing part of the application's memory section during the initialization of a custom-made memory handler module.

View solution in original post

1 REPLY 1
LucasRosa
Associate II

Hello guys, I found out what was wrong. It turns out I was accidentally erasing part of the application's memory section during the initialization of a custom-made memory handler module.