2019-11-13 07:52 AM
I'm getting a hard during the idle task creation of a minimal out-of-the-box cmsis-osv2-freertos project.
Setup:
Compiling and running the project on target results in a hard fault during creation of the idle task. Memory in the stack is being corrupted by the memset call at:
Thread #1 [main] 1 [core: 0] (Suspended : Breakpoint)
prvInitialiseNewTask() at tasks.c:847 0x8002252
xTaskCreateStatic() at tasks.c:615 0x80021a4
vTaskStartScheduler() at tasks.c:1,909 0x80024ce
osKernelStart() at cmsis_os2.c:207 0x80013d0
main() at main.c:129 0x8000194
Reset_Handler() at startup_stm32f103c8tx.s:97 0x8000482
Variables:
pxTaskCode TaskFunction_t 0x8002b69 <prvIdleTask>
pcName const char * const 0x8003cf4 "IDLE"
ulStackDepth const uint32_t 128
pvParameters void * const 0x0
uxPriority UBaseType_t 0
pxCreatedTask TaskHandle_t * const 0x20000168 <Idle_Stack+220>
pxNewTCB TCB_t * 0x20000030 <Idle_TCB>
xRegions const MemoryRegion_t * const 0x0
pxTopOfStack StackType_t * 0x20000da0 <ucHeap+132>
x UBaseType_t 536874416
This results a hard fault in the next executable line:
prvInitialiseNewTask() at tasks.c:857 0x8002262
Variables:
pxTaskCode TaskFunction_t 0xa5a5a5a5
pcName const char * const 0xa5a5a5a5 <error: Cannot access memory at address 0xa5a5a5a5>
ulStackDepth const uint32_t 2779096485
pvParameters void * const 0xa5a5a5a5
uxPriority UBaseType_t 2779096485
pxCreatedTask TaskHandle_t * const 0xa5a5a5a5
pxNewTCB TCB_t * 0xa5a5a5a5
xRegions const MemoryRegion_t * const 0xa5a5a5a5
pxTopOfStack StackType_t * 0xa5a5a5a5
x UBaseType_t 2779096485
This feels like the problem is with the configMINIMAL_STACK_SIZE parameter controlling the stack depth, but the units of 128 words seem to be consistent from Idle_Stack through the memset.
When I switch the project to cmsis_osv1, it runs without problems. BUT tskSET_NEW_STACKS_TO_KNOWN_VALUE is unset by default. Setting check for stack overflow to option 2 enables the memset and the same corruption occurs.
Any suggestions? Did I miss a configuration step?
Thanks,
Ben
2019-11-13 07:59 AM
STM32CubeIDE version 1.1.0
STM32Cube FW_F1 V1.8.0
2019-11-14 06:46 AM
I noticed the same problem and found that increasing the main thread's stack fixed the problem.