Closed fietser28 closed 19 hours ago
tests/freertos_syscallmutex
fails to make progress in certain tasks.I scanned the issues but not the branches and pull request.
I did some digging and maybe found something: Adding a delay in the start of the threads solves the problem for this test.
You can find a working test at: https://github.com/fietser28/arduino-pico-freertos-test
Cool, thanks! Doesn't pinpoint anything but now there's a hack I can examine to see what goes differently inside the kernel. Should be no need to sleep before the while(1)
especially since there's a delay
in every loop...
I did some tests to try to help pinpoint and can share the following:
The main test case is after 10 seconds of running: from loop a call to vTaskCoreAffinitySet is done to change the affinity of loop2. This is similar to the original behaviour where after a createTask a vTaskCoreAffinitySet is done but the thread is already running then (that's the way Arduino-pico works) and I avoided that scenario with the delays at the start of the threads. Using this code:
I've made an update to the repo https://github.com/fietser28/arduino-pico-freertos-test. Setting:
#define BUSY_MALLOC 1
will result in a crash.
define #BUSY_LOOP 1
will result in a program that keeps running.
I suspect (but not sure) the malloc-lock.cpp needs to be made FreeRTOS compatible. Maybe using pvPortMalloc/pvPortFree when FreeRTOS is being used?
The port
prefix is generally for "ported" calls in FreeRTOS AIUI. pvPortMalloc
is something the app implements to give to FreeRTOS to do it's work. We implement that, using FreeRTOS mutexes, already (or else the RP2040 implementation would fail and most FreeRTOS apps there would simply not even start up).. We use Newlib's malloc
implementation, not gcc
's FWIW.
Thanks, though, for verifying the RP2350 SDK branch is clean. It doesn't support things like multicore flash writes (or it didn't when I did my original port...I seemed to run into that before the SDK guys did unluckily), but maybe that's a hint. If they're using the intercore FIFO in a different way on the 2350 vs. the 2040 then all bets would be off...
Did some more digging (and a lot of learning how all the libraries interact) and came up with this change. When using FreeRTOS I think the handling of critical sections should also be done via FreeRTOS calls. This suddenly made some cases work. Will need to test for more cases.
Done
Hello,
Thank you for creating Arduino-pico, I'm a very happy user using rp2040! I'm also impressed how far the RP2350 support already is. Unfortunately for me the main project I'm creating depends on FreeRTOS.
As you stated there is currently no support for FreeRTOS. I've noticed however that raspberry pi have created a FreeRTOS clone with RP2350 support (for ARM M33 cores and based on existing implementation). The repository is: https://github.com/raspberrypi/FreeRTOS-Kernel
Would this help to get FreeRTOS working for rp2350s in Arduino-pico without to much effort?