RTEMS crash with error 18 (RTEMS_CALLED_FROM_ISR) again.
nick.thomas at pixsan.com
Wed Feb 17 17:27:00 UTC 2010
Hi, thanks again for your input.
> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> Sent: 17 February 2010 17:04
> To: Nick Thomas
> Cc: rtems-users at rtems.com
> Subject: Re: RTEMS crash with error 18 (RTEMS_CALLED_FROM_ISR) again.
> On 02/17/2010 10:56 AM, Nick Thomas wrote:
> > Does that prove that it came from a task context?
> Depends. Sometimes on some targets, the trace from an ISR can follow
> back through from the ISR to the interrupted task. Do you see any of
> the ISR entry code in the back trace?
The backtrace doesn't go through any code that I recognize as ISR related.
> If there is no hint of being in an ISR (bit in PSR?), then there is
> something out of sync -- an ISR exit path which doesn't decrement the
> count, code which thinks it is in the register but it is in
> _ISR_Nest_level, or vice-versa.
_ISR_Nest_level is zero.
Does the _System_state_Get function have anything to do with this?
It appears just before the Error 18 is set, and _Internal_error_Occurred is
What does _System_state_Get function do for us here?
Sometimes I have noticed the system will hang (lock up - not crash) with
_ISR_Nest_level stuck at 1. This has prevented tasks from running as the
system thinks it is constantly in an ISR.
I can manually flip _ISR_Nest_level back to zero (through BDI2000 debugger
interface) and then the tasks start running again, for a short while - until
a real crash occurs :(
I guess that also suggests that something is out of sync.
> The vectoring code is board dependent in your RTEMS version and this
> was fragile. It could be a very specific path in your BSPs version of
> this code.
> > Regards
> > Nick
> Joel Sherrill, Ph.D. Director of Research& Development
> joel.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
More information about the users