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: /* 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 SysTickHandler defined within STM32Cube HAL */ /* #define xPortSysTickHandler SysTickHandler */ 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

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

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.

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

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

Is there any possibility that interrups are not configured properly?

Please help!

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?

Thank you, will try all your suggestions.

I have replaced all functional bodies of my 4 tasks with test code like: HALGPIOTogglePin(GPIOC,STATUSLEDOUT_Pin); osDelay(500); 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?

Timer 6 is used as HAL time base source.

Hi Anani, Did you get anywhere with this issue?

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