I am trying to use the FreeRTOS Windows port for a software test environment for one of our applciations. I was able to get the FreeRTOS Win32 LED Blink demo up and running, but when I started making changes to it, I noticed some odd behavior.
If I remove the printf statement so that nothing is printed to the console, the application blocks the Task Manager. I cannot open the Task Manager and if it was open before I start the application, then the Task Manager stops responding. If I slow down the rate of printf statements in the application, I can clearly see that the Task Manager only updates when the printf statement is run. This makes it very difficult to recover if something goes wrong in the application and locks up my PC.
Has anyone else ran into similar behavior with the Win32 port? Any thoughts on why this may be happening and how it could be resolved? I’d rather not just arbitrarily print to the console if I don’t need to.
The Windows port requires a host with more than one core as all the
FreeRTOS threads are tied to the same core, and recent versions of the
simulator raise the priority of those threads so they are really high.
Older versions of the simulator, written before most PCs were multicore,
used lower priorities. Does the Windows machine you are running this on
have more than one core? Currently it sounds like the only time other
Windows threads are running is when the FreeRTOS code is waiting for
Windows system calls to complete.
I am running on an HP ZBook with an quadcore I5 and 8gb of RAM.
When I run the application it spikes Core 1 to 100%. The other cores are stay at around 30-40%. I can usually access other programs in along with my application. It is only Task Manager that is blocked completely.
Is it possible that it is because the FreeRTOS application is consuming Core1? Is it possible to force the application onto a specific core?
I have never noticed this behaviour. To experiment with using a
different core open FreeRTOS\Source\portable\MSVC-MingW\port.c, then
search for all occurrences of SetThreadAffinityMask(). Unfortunately it
does not use a #define to set the affinity, so you will have to update
each occurrence.
I did find the SetThreadAffinityMask and forced it to run on core 4. It didn’t change the overall behavior other than forcing core 4 to 100% use. Task Manager is still blocked if printf isn’t called often.
This is also happening on other computers here (not sure on their hardware config), so I know it’s not just me.
I’ve just tried this on my quad core running Windows 10 and FreeRTOS
V10.0.1. I removed the calls to printf() and can still open the task
manager while the code is running, and the task manager appears to be
behaving normally.
I just got back to being able to test this. I have to appologize, as I didn’t quite have all the variables when I initially posted. I thought it was just the printf, but it’s not. The issues seems to stem from having only tasks that block on vTaskDelayUntil.
I took the v10.0.1 Windows MSVC demo directly from source forge. I opened it in VS2017, and I set the define to use the Blinky Demo. I then commented out the call to xQueueSend in the prvQueueSendTask so that all that task is doing is calling the vTaskDelayUntil and suspending for 200ms.
When I do that, it completely blocks Windows Task Manager.
If I try to add more “stuff” (like a for loop counter) to prvQueueSendTask, so that it’s not doing nothing, it does not change behavior.
If I add a printf("."); to prvQueueSendTask, then Task Manager will update anytime the printf is called. If I uncomment the xQueueSend call, then again I can see Task Manager update.
Hopefully that will give you the correct information so you can reprocuce the issue.
I had a coworker try and he was able to replicate the issue on his machine. Looking back through the posts, the only difference I can see is that we’re on Windows 7 and you’re on Windows 10. I will try to hunt down a system with Windows 10 on it to try, but if you had a Windows 7 system, that could be an avenue to explore.