PlatformIO Community

STM32FreeRTOS vTaskDelay() not returning

I’m still having a problem with the frBlink code. ‘vTaskDelay()’ does not execute and return. I added print statements before and after to verify.

I tried the same code in the Arduino 1.8.12 IDE and it works as there.

Tried a couple things I found on this site, but no solution. Any help is appreciated.


Dependency Graph
|-- <STM32duino FreeRTOS> 10.0.1
Building in release mode
Compiling .pio\build\bluepill_f103c8_128k\src\main.cpp.o
Linking .pio\build\bluepill_f103c8_128k\firmware.elf
Checking size .pio\build\bluepill_f103c8_128k\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]   6.3% (used 1288 bytes from 20480 bytes)
Flash: [==        ]  15.7% (used 20612 bytes from 131072 bytes)

There is a problem with the linking process. FreeRTOS needs to hook the weak SVC_Handler (supervisor-call interrupt) in order to be able to execute a task switch. However the way PIO builds the firmware, it builds the Arduino framework first and creates an .a archive. When this happens the FreeRTOS code hasn’t been looked at yet but the SVC_Handler gets its default empty function. Then the FreeRTOS code is compiled an archived and both archives are linked together, however FreeRTOS doesn’t get the SVC_Handler call then because it’s already occupied.

This is prevented by using the lib_archive = no option (docs) which does not create archives but links all objects file together, and then linking works and FreeRTOS’s SVC_Handler is called.

You can go into your project’s platformio.ini and add

lib_archive = no

which makes the blinky project work.

The library.json of the FreeRTOS library tries to use the exact same setting but it isn’t applied somehow.

I’ll check why.

Issue created at

Fantastic! It works. I had seen that issue and thought maybe the library.json file didn’t contain it for freertos 10.0.1, but it did.

Thank you for you thorough explanations. I owe you lunch.


Thanks @John for posting this, and @maxgerhardt for the workaround. I just spent a day+ trying to figure out what I was doing wrong and looking at the old (fixed!) bug reports. Hope this gets resolved soon.