We are using the Windows Simulator to simulate our application. Occationally the FreeRTOS list structures seem to get out of step and the RTOS locks up. There does not appear to be any memory corruption. All the values look resonable. The cases are: Adding and entry to a list that is already in the list and removing an entry from a list where the Container field is NULL. The issue is related to using semaphores and events. We are running several FreeRTOS threads. Each seems to get its own Windows thread. xTaskRemoveFromUnorderedEventList() says it must be called with the sheduler suspended. But you can’t suspend the Windows scheduler. Is there fix for this? Any ideas?

I’m afraid I don’t know if there is a fix because I don’t know what the issue is. Is the case you provide (adding an entry to a list that is already in the list) what you are trying to do, or what the symptom is when the problem occurs? I would need an lot of information on the lead up to this case to begin to surmise what the causes may be. The part you refer to where it says the scheduler must be suspended is talking about the FreeRTOS scheduler, not the Windows scheduler. Assuming you are not trying to communicate between FreeRTOS tasks (which run in Windows threads, but that is transparent to the tasks themselves, just an implementation detail) and Windows threads that are created outside of the FreeRTOS application (so threads you would have to use Windows API calls to communicate with rather than FreeRTOS API calls) then you don’t need to consider the Windows scheduler at all. Have you edited any of the FreeRTOS implementation? Even if you think it is not significant? Are you creating any Windows threads yourself, other than the threads that are created by the FreeRTOS scheduler in the Windows port layer. Are you able to demonstrate the issue in a project that is cut down to the bare bones and can be sent to us?