I am busy debugging STM32F100RCT MCU project. The project framework and FreeRTOS code are generated by STM32CubeMX. I was debugging (ST-Link) without any FreRTOS related issues for a couple of weeks. Suddenly prvPortStartFirstTask() execution crashed… I have checked some similar issue posts published here, but still no clue. It looks like I have all settings correct:
static void prvPortStartFirstTask( void )
{
__asm volatile(
" ldr r0, =0xE000ED08 \n" /* Use the NVIC offset register to locate the stack. /
" ldr r0, [r0] \n"
" ldr r0, [r0] \n"
" msr msp, r0 \n" / Set the msp back to the start of the stack. /
" cpsie i \n" / Globally enable interrupts. /
" cpsie f \n"
" dsb \n"
" isb \n"
" svc 0 \n" / System call to start first task. */
" nop \n"
);
}
ASM stepping is stacked at line: svc 0 \n" /* System call to start first task. */, when I tried to run the debbuging again, it crashes.
In FreeRTOSConfig.h I have what is required:
/* USER CODE BEGIN 1 / #define configASSERT( x ) if ((x) == 0) {taskDISABLE_INTERRUPTS(); for( ;; );}
/ USER CODE END 1 /
/ Definitions that map the FreeRTOS port interrupt handlers to their CMSIS
standard names. / #define vPortSVCHandler SVC_Handler #define xPortPendSVHandler PendSV_Handler
/ IMPORTANT: This define MUST be commented when used with STM32Cube firmware,
to prevent overwriting SysTick_Handler defined within STM32Cube HAL /
/#define xPortSysTickHandler SysTick_Handler */
And in port.s I have the handler:
void vPortSVCHandler( void )
{
__asm volatile (
" ldr r3, pxCurrentTCBConst2 \n" /* Restore the context. /
" ldr r1, [r3] \n" / Use pxCurrentTCBConst to get the pxCurrentTCB address. /
" ldr r0, [r1] \n" / The first item in pxCurrentTCB is the task top of stack. /
" ldmia r0!, {r4-r11} \n" / Pop the registers that are not automatically saved on exception entry and the critical nesting count. /
" msr psp, r0 \n" / Restore the task stack pointer. */
" isb \n"
" mov r0, #0 \n"
" msr basepri, r0 \n"
" orr r14, #0xd \n"
" bx r14 \n"
" \n"
" .align 2 \n"
“pxCurrentTCBConst2: .word pxCurrentTCB \n”
);
}
The SVC instruction effectively calls vPortSVCHandler(), which in turn
starts the first task running. Often people step through to the SVC
instruction when debugging and think the crash is occurring there -
whereas in fact unknown to them the debugger has started a task
executing and the crash actually happens in the task.
First set a break point in vPortSVCHandler() to see if it gets hit. If
it does step through that program to see which task runs first. If you
actually get into a task then something is going wrong in a task, not
when starting the scheduler.
You need to know where the MCU is jumping to when it calls the SVC
instruction. Interrupts must be enabled at that point as the asm code
prior to the SVC call enables interrupts. Could it be there is another
SVC handler? Perhaps one defined by the cube software?
Something is happening when SVC is called. The CPU is branching
somewhere. You need to find where. Interrupt priorities are not the
problem at that point in the code, but could be later if the SVC is
actually starting the scheduler running and you just don’t realise it.
Do you have a break point in your hard fault handler too? Could you be
ending up in a hard fault?
The project compiled and linked, but debugging came with random errors, different for each attempt:
No source available for “SystemCoreClock() at 0x20000004”
No source available for “ucHeap() at 0x200001e2”
Then I have enabled one of the tasks and debugging was OK.
I have allocated 16384 bytes heap size for FreeRTOSand 512 words stack per task (4 tasks). I am using static heap_1 memory management scheme. In Atollic the min. page of malloc is 128bytes.
Please advise me what could be the cause of such unpredicted behaviour?