I am seriously considering using FreeRTOS over the current Keil RTX O/S I am currently strapped into. It seems the RTX kernel has/had a bug in it with how it handles interrupt servicing (I found this thread by luck if anyone is interested, or for a complete understanding of this issue - http://www.keil.com/forum/docs/thread15346.asp).
As I am using an 'older' version of RTX than what is currently supported by the manufacturer I would have to jump through alot of hoops I am not interested in revisting (in addition to waiting who knows how long for a fix).

My question is: Has this 'undocumented' problem already been addressed (or does it even need to be addressed) with the latest FreeRTOS release? BTW: I am using a NXP LPC2136/01 processor. Thanks.

Thats a very long thread, and only mentions the cause of the problem vaguely at the bottom. I don't understand exactly what the problem is - sounds like spurious interrupts, which are a well documented feature of the VIC. Can you shed some more light on exactly when the problem occurred and what the fix was?

Regards.

Specifically, the 19 posts states the problem and the solution is a 'few weeks away'. Basically here is the gist of the problem (which, your right, sounds very much like the NXP documented Spurious Interrupts chapter) :

"The actual reason for all the sporadic occasional RTX failures you have been seeing is most likely due to the NXP LPC2xxx VIC undocumented "feature" (described bellow) and that RTX was not aware of this.

VIC behavior: After an interrupt is disabled (writing to VICIntEnClr) the interrupt is not immediately blocked but can still happen for a few cycles (time needed for VIC to process the request). Special tests were performed which confirm this behavior.

This "feature" was not taken into account by the RTX kernel. Therefore in some rare situations (very timing specific) it could happen that a blocked interrupt was still executed which eventually lead to RTX failure. Such situations are very rare (can happen sooner when the system time tick interrupt happens more often) and even less likely when the MAM is disabled because then an instruction fetch takes longer then the few cycles that VIC requires. This explains also why the problem was not detected sooner and why it was almost gone when MAM was disabled."

Ok - reading this again here I see I misread it the first time. It is talking about the VICIntEnClr register, which I don't think the FreeRTOS kernel itself ever writes to. Presumably they (being Keil) provide a library for setting and clearing interrupt enable bits, and this is the code that they are going to change? FreeRTOS does not have an equivalent, the interrupt enable and disable registers are at the mercy of the application developer.

Regards.

Beautiful! Thanks for the info....