FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [September 2009 Threads] NXP ARM 7 Interrupt ServicingPosted by Toil In Obscurity on September 10, 2009 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.
RE: NXP ARM 7 Interrupt ServicingPosted by Richard on September 10, 2009 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.
RE: NXP ARM 7 Interrupt ServicingPosted by Toil In Obscurity on September 10, 2009 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."
RE: NXP ARM 7 Interrupt ServicingPosted by Richard on September 10, 2009 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.
RE: NXP ARM 7 Interrupt ServicingPosted by Toil In Obscurity on September 10, 2009 Beautiful! Thanks for the info....
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|