As far as I can tell, thread.js has never worked properly. I once posted a correction to the algorithm for traversing the data structures, but even that was not right. But a more serious problem was a crash of CrossStudion when switching to the Idle thread context.

I have finally determined the problem and will explain here. I will also send a corrected threads.js to Richard Barry.

This problem is a strange one. In threads.js a function Debug.Evaluate() is used to poke into the object code being debugged. All variables accessed should be known in the current debug context. Oddly (and apparently unknown to Rowley), if they are not known because they are static in some other context then the value returned is the address of the variable rather than the value of the variable. The original FreeRTOS threads.js exploits this idiosyncracy and just dereferences values that are static in tasks.c. Unfortunately if you switch to the context of the Idle task (which has visibility into tasks.c) then addresses are not returned but the proper values are. This crashes threads.js and consequently CrossStudio.

Recent FreeRTOS versions of tasks.c make use of aportREMOVE_STATIC_QUALIFIER, a preprocessor macro. With portREMOVE_STATIC_QUALIFIER defined, statics in tasks.c become extern instead. This gives them global visibility. With '#define portREMOVE_STATIC_QUALIFIER' in portmacro.h, and modifying threads.js to lose the extra dereferencing of Debug.Evaluate() accessed data, we get a working system.

The threads.js I am sending to Richard also fixes the traversing of the TCB lists. I can send it to users if they email me at... glen at EmbeddedClarity dot com.

Glen

Excellent work Glen - I have the file you sent. Thanks!

Regards.