RTEMS crash with error 18 (RTEMS_CALLED_FROM_ISR) again.

Joel Sherrill joel.sherrill at OARcorp.com
Wed Feb 17 21:24:17 UTC 2010


On 02/17/2010 03:08 PM, Nick Thomas wrote:
>>>        
>> 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.
>>>>
>>>>          
>
> Looking at _CORE_mutex_Seize in coremutex.h. This is the inlined function
> where the error 18 is generated.
> Note, that 18 is hard coded in there. I was searching for the RTEMS_XXX
> defined constant !
>
> So, the error will be generated if:
> _Thread_Dispatch_disable_level>  0 AND _wait is TRUE AND _System_state_Get()
>    
>> = SYSTEM_STATE_BEGIN_MULTITASKING.
>>      
> Now, _wait is always TRUE, and I assume that _System_state_Get() also
> returns TRUE after the system has been running for a while before the bug
> happens.
>
> So, it looks like the culprit here is the _Thread_Dispatch_disable_level
> variable.
>
>
> I will wait for the crash to happen again, and check it's value.
>
>    
Hmmm... in 4.7.x, it is possible that the stack checker is
using printf which would be trying to lock a mutex.  It was
changed to printk() some time past that point. Do
you have stack checking on?
> 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 mailing list