FreeRTOS simulator on windows deadlock with standard libraries

alpmkn wrote on Monday, July 28, 2014:

Dear All,

Our application freezes after a while. The problem seems to be the use of the standard C++ libraries.
In the standard libraries a critical section is used which results in a dead lock of the application.

The running threads is then locked in a critical section which is not known by FreeRTOS. If the thread that is running has a higher priority no other tasks will run. We found that this problem can occur immediately or after a period of time.

In the example project of the FreeRTOS windows simulator we created a timer and a thread. The timer uses a map and sends something using a FreeRTOS queue. The task waits forever for the queue and then prints the value in the map to the console.

I have included an adaptation (as described above) of the example code where the deadlock also happens (but is catched by the IDLE task and it comes into an assert).

Is there anything we overlooked in working with FreeRTOS and Windows and is there anything we can do to prevent the deadlocks?

I hope to hear from you soon,

Best regards

rtel wrote on Monday, July 28, 2014:

I’m afraid Windows programming is a little outside my scope of expertise. From your post it sounds like the windows library is causing the problem, and presumably when you are running the code on your real target the library will be completely different and probably not have the same issue.

Without knowing the full scenario I’m not sure why the thread that has entered a Windows critical section would not also exit the critical section before running any more of your FreeRTOS code though assuming the enter and exit of the windows critical section is within the same Windows library function.

Here would be some suggestions:

  • Use a different library while using the simulator - either by implementing small parts of the library yourself or by building in a library from a third party.

  • See if there are any compiler options that allow the selection of non-multi-threaded libraries that won’t include these critical section.

  • Maybe if possible re-implement the critical section called by the library to use a FreeRTOS [simulated] critical section instead so the library links to your version rather than the library’s version.