Hello,
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
__disable_irq();
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
SYSCFG->CFGR1 |= (SYSCFG_CFGR1_MEM_MODE_0 | SYSCFG_CFGR1_MEM_MODE_1); // MEMMODE = 3
void (*mainprog) (void) = (void (*)) *(__IO uint32_t*)(FIRMWARE_START_ADR + 4); // +4 to call the Reset_handler of the vector table
mainprog();
// code should never run here
while(1){
assert(0);
}
}
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:
You probably need to program VTOR to correctly install the application vector table. This is a useful article from ARM - Documentation – Arm Developer.
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
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
okay i missunderstood this.
So what this defines do is that an SVC or PendSV Interrupt call the freeRTOS handler
xPortPendSVHandler and vPortSVCHandler ?
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?
