RTEMS crash with error 18 (RTEMS_CALLED_FROM_ISR) again.

[Joel Sherrill]

On 02/17/2010 11:27 AM, Nick Thomas wrote:
> 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.
>
>    
Is this a target that doesn't use _ISR_Nest_level?
I know you looked before but can you double check. :)
> 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
> called.
> What does _System_state_Get function do for us here?
>
>    
Tells you if the system is up, initializing or shutting down.
> 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.
>
>    
Yes.  That's the hint.  A path out of the ISR code isn't doing
exactly the right thing.
>
>    
>> 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.
>>
>> --joel
>>      
>>> 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
>>      
>
>    


-- 
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