Well despite all my best efforts, I am now convinced that the port of FreeRTOS with ProcessorExpert is not correct. I could go into the gruesome details of what I am seeing, but I would rather just poll the community and ask if anyone has had better success with using FreeRTOS with KDS? I have tons of experience with FreeRTOS and I know the kernel is fine, it is widely deployed. I also think I know what I am doing with implementing a FreeRTOS-base program. But when a task variable is getting corrupted by merely the action of passing it via a queue, and I have the task stack depth to 2K with hardly any deep calls, something ain't right. The tasks I have do not do anything, but receive this message and pass it along. I am actually at a lost to the cause, but all ideas welcome....

Erich, who knows most about the processor expert, is at the Freescale Technology Forum this week, so I'm going to have to start with some more basic questions:

Which version of FreeRTOS is it using (the comments at the top of each FreeRTOS source file will tell you that)?

Does the FreeRTOSConfig.h file you are using have configASSERT() defined?

The reason for asking these questions first is the number of configurations errors configASSERT() will catch depends on the FreeRTOS version.

Regards.

Sorry I have been very frustrated with this dev env. that I forgot my normal details: FreeRTOS Version : 8.0.1 configAssert has been defined heap size set to 16384 total number of task allowed : 8 total defined 3 with configMINIMALSTACKSIZE at 128 total queues defined 2 with depth of about 5 small elements memory allocation scheme is heap_1.c running KDS 3.0.0 on Win7 using tickless idle mode as we are sleeping the processor until it is woken up with an accelerometer generated interrupt. there are a few FreeRTOS timers in use and one mutex.

Hi William, I see that you have posted the same question to the Freescale Forum. I will follow-up there, as I believe you might not have set the interrupt priorities correctly or there might be an undetected stack overflow.

Erich