FreeRTOS crashes when called from Bootloader ARM Cortex M0

i have a typical bare metal bootloader and freeRTOS Application szenario. The Target is a STM32F030RC ( Arm Cortex M0)
When the bootloader jumps to a bare metal application everything is fine, but when the bootloader jumps to the freeRTOS application the application crashes.

I know that i should manipulate as less registers as possible from within the bootloader.
Therefore i have this minimal version that only inits the clock tree and than jumps to the application (this code snippet works with bare metal application but not with freeRTOS application) . I also have defined NMI_Handler, HardFAult_Handler and Systick_Handler in the bootloader code but they are only defined but never called when i reduce the bootloader to this snippet.

The Bootloader code:

void main()
    clock_init(); // Configures only RCC Registers

	for(unsigned int i=0; i< RAM_VECTORTABLE_LEN;i++){
		ram_vectortable[i] = *(__IO uint32_t*)(FIRMWARE_START_ADR+(i<<2));
	RCC->APB2ENR |= RCC_APB2ENR_SYSCFGEN; // Sysconfig Clock must be enabled to work

	void (*mainprog) (void) = (void (*)) *(__IO uint32_t*)(FIRMWARE_START_ADR + 4); // +4 to call the Reset_handler of the vector table
	// code should never run here

When i try to debug the application i see this backtrace:
I can’t really Debug the Application. I think the reason is that the application is already started from the bootloader or maybe a incomplete startup setup.

My Debug Configuration for the Application looks like this:

My Flash-Layout looks like this:

Thanks for all your advices.

You probably need to program VTOR to correctly install the application vector table. This is a useful article from ARM - Documentation – Arm Developer.

No the cortex M0 has no VTOR.
For this reason i copy the vector table to the SRAM and than change the memory-mode to MEMMODE_3.
There are a lot of tutorials how to do this for a cortex M0.
I like this one:

Alright - my bad. Have you installed FreeRTOS handlers for SVC, SysTick and PendSV - FreeRTOS-Kernel/portable/GCC/ARM_CM0/port.c at main · FreeRTOS/FreeRTOS-Kernel · GitHub?

Right - that’s M0+ with VTOR. Basic M0 does not have VTOR but silicon vendors like ST can provide a way to shadow RAM at address 0x00000000 allowing you a RAM-based vector table.

Regarding the question from @aggarg – to install the FreeRTOS vectors you would typically have something like this in your FreeRTOSConfig.h:

/* Map the FreeRTOS port interrupt handlers to their CMSIS standard names. */
#define vPortSVCHandler     SVC_Handler
#define xPortPendSVHandler  PendSV_Handler
#define xPortSysTickHandler SysTick_Handler

Yes is have mapped the freeRTOS Port Interrupt Handlers to their CMSIS Standard names.

#define vPortSVCHandler    SVC_Handler
#define xPortPendSVHandler PendSV_Handler

and a custom redefinition of the SysTick_Handler.
This was necessary to avoid startup problems.

void SysTick_Handler(void) {
	if (xTaskGetSchedulerState() != taskSCHEDULER_NOT_STARTED) {

but for PendSV_Handler this means that freeRTOS functions call the Default_handler, which is a endless while loop.
Al this is defined in the startup_stm32f030rctx.S which has no customization by me


  .weak      SVC_Handler
  .thumb_set SVC_Handler,Default_Handler

  .weak      PendSV_Handler
  .thumb_set PendSV_Handler,Default_Handler

This is not correct - xPortPendSVHandler needs to be called for PendSV interrupt and vPortSVCHandler for SVC.

okay i missunderstood this.
So what this defines do is that an SVC or PendSV Interrupt call the freeRTOS handler
xPortPendSVHandler and vPortSVCHandler ?

#define vPortSVCHandler    SVC_Handler
#define xPortPendSVHandler PendSV_Handler

That means for me that i have done this right so far, am i correct ?
So how can i debug what kind of Problem the freeRTOS has ?

This defines changes the name of xPortPendSVHandler to PendSV_Handler and vPortSVCHandler to SVC_Handler in the preprocessing step so that definitions provided by FreeRTOS are used instead of the weak definitions in the startup code.

Can you examine the vector table entries and see if handlers for SVC and PendSV are correctly installed? Is it possible for you to share your complete code?

i have found my bug.
i forgot the RAM offset in the application


  RAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 32K
  FLASH    (rx)    : ORIGIN = 0x8008000,   LENGTH = 256K - 32K

STM32F030RCTX_FLASH_APPLICATION.ld (with bugfix)

  RAM (xrw)      : ORIGIN = 0x200000BC, LENGTH = 32K - 0xBC /* The Vector Table in RAM (size = 4x47Byte) must not be used by the application*/
  FLASH    (rx)    : ORIGIN = 0x8008000,   LENGTH = 256K - 32K

My bare-metal application with the buggy linker-script only worked, because it never called any entry of the vector table.

Thank you for reporting back!