STM32F100RCT MCU + STM32CubeMX project: prvPortStartFirstTask() crash

anani wrote on Thursday, June 15, 2017:

Hi All,

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:

#define configASSERT( x ) if ((x) == 0) {taskDISABLE_INTERRUPTS(); for( ;; );}
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”

Please help!

Best regards,

anani wrote on Thursday, June 15, 2017:

Sorry, forgot to mention, working with Atollic v7.1.2 Lite, FreeRTOS V8.2.3 (comes with Cube).

rtel wrote on Thursday, June 15, 2017:

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.

anani wrote on Thursday, June 15, 2017:

Thank you for the advice. I have done what you suggested, didn’t hit the break point though… Please advise what to try next.

anani wrote on Thursday, June 15, 2017:

ST Link crashed and Debug perspective disappeared, went back to C/C++ perspective.

anani wrote on Thursday, June 15, 2017:

Is there any possibility that interrups are not configured properly?

anani wrote on Friday, June 16, 2017:

Please help!

rtel wrote on Friday, June 16, 2017:

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?

anani wrote on Friday, June 16, 2017:

Thank you, will try all your suggestions.

anani wrote on Friday, June 16, 2017:

I have replaced all functional bodies of my 4 tasks with test code like:


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?

anani wrote on Friday, June 16, 2017:

Timer 6 is used as HAL time base source.

sgilbert wrote on Tuesday, January 09, 2018:

Hi Anani,

Did you get anywhere with this issue?

gawrcool wrote on Friday, March 30, 2018:

Remove compile with optimisation (-o1). Did the trick for me