I’m trying to migrate a FreeRTOS application running on the PI PICO RP2040 to the SMP branch. After spending days of debugging randomly freezing TickCount I’m really frustrated:
First of all I’ve found that PRIMASK was set
Then I increased the minimum Stack from 512 to 2048
Then I got a StackOverFlow (configCHECK_FOR_STACK_OVERFLOW = 2) from an Idle-Task (didn’t found out why the hell this happens, and why this happens after the increased value and not before).
And I’m not really happy by increasing configMINIMAL_STACK_SIZE for all tasks, because 3/4 of my tasks only needs 512 words stack size.
After that I’ve got some SMP race conditions because (assert in configASSERT( portGET_CRITICAL_NESTING_COUNT( xCoreID ) == 0 ))
on one core I’ve created a new static task (with xTaskCreateStatic and also with xTaskCreateStaticAffinitySet, while the other tried a context switch. This I’ve solved with taskENTER_CRITICAL() vTaskSuspendAll xTaskCreateStaticAffinitySet xTaskResumeAll taskEXIT_CRITICAL()
One core tries to start a timer while the other ones makes a context switch
So, first things first:
Was anyone able to create a SMP project successfull?
Based on all this crude race condition scenarios - is there a tutorial available to avoid them, or how to port a “normal” application to SMP (I think there are some new booby traps)? I was surprized that simple task creation or timer starting within a running task just with FreeRTOS API leads to this errors (e.g. static tasks should be created before scheduler starts?)
How to deal with the Idle-Task(s) stack - which size should they have?
Why isn’t vApplicationStackOverflowHook triggered if stack size is to small? This happens after I increased the size?
There is no fixed method to calculate but you should be able to use the value from the above mentioned demos.
The stack overflow check if not guaranteed to trigger vApplicationStackOverflowHook always on platforms which do not have stack overflow check support in hardware (RP2040 does not have stack overflow check support in hardware). This is because stack overflow checs is performed only during a context switch , and an overflow might occur and lead to crash before the next context switch.
I have been using SMP on the pick’s for two years I think and it runs fine and reliable. There was one patch I needed to apply. I used the latest rabies compiler, latest FreeRTOS and SDK.
I remember I had to fiddle a bit with stack sizes and some settings, also because I use UDP, TCP and other networking using LwIP including Bluetooth.