Internal_errors_What_happened = 18? (RTEMS_CALLED_FROM_ISR)

[Nick Thomas]

> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> Sent: 01 February 2009 22:42
> To: Nick Thomas
> Cc: rtems-users at rtems.com
> Subject: Re: Internal_errors_What_happened = 18?
> (RTEMS_CALLED_FROM_ISR)
> 
> Nick Thomas wrote:
> > Hi,
> > This is my first post here, and my first use of RTEMS.
> >
> > "Oh great, another newbie", I hear.
> >
> >
> This isn't a typical newbie question.  :-D
> > My apologies if this question has been answered before, I did look
> > through the mailing list archives, but couldn't find anything
> > obviously related to my issue.
> >
> > I have PPC405 processor, trying to run RTEMS.
> >
> > It gets through initialization, and gets well into running my code,
> > but locks up at roughly the same place (as far as I can tell).
> > I am debugging using a BDI2000 - JTAG thing.
> >
> > So, I see "007cc0f8 B Internal_errors_What_happened" in the symbols
> > table, and when I do 'md 0x7cc0f8' in the debugger screen I see from
> > the Internal_errors_Information struct that:
> >  The_source = 0,
> >  Is_internal = 0,
> >  The_error = 18 (decimal).
> >
> >
> You need to look at cpukit/score/include/rtems/score/interr.h
> to decode that structure.  The 0 for "the_source" indicates that the
> supercore generated it not a classic API call.  So the error code is
> actually of type Internal_errors_Core_list and if I am counting right,
> it is INTERNAL_ERROR_MUTEX_OBTAIN_FROM_BAD_STATE
> which should be indicating you tried to obtain mutex from an ISR or
> before multitasking is started and the mutex was NOT available and you
> were going to block.  Since you are in a system state that is NOT a
> task, this is an error.
> 
> It is a fatal error because it indicates a design issue you need to
> correct.
> 
> Now the newbie question: Did you try to printf?
> 
> You should be able to set a breakpoint there and back trace in gdb to
> see where you came from.Changing printf to printk may be enough to fix
> it.


Hi Joel, thanks for the answer. Still out of my depth here though.
I checked the 'Current LR' from the 'info' command, and it showed me that it
was indeed coming from rtems_semaphore_obtain().
So, I am calling this func from some ISR. But, I don't see a 'back trace'
command in my telnet session.
And I can't find bdiGDB on my system!

Thanks,



> > As far as I can tell, '18' means RTEMS_CALLED_FROM_ISR (called from
> > wrong environment).
> >
> > So, I got this far - but how do I work out what rtems call is being
> > called in the wrong environment.
> >
> > Seems to be referring to something involving the core mutex. Now, is
> > this because I am mis-using semaphores/mutex in my code, or is
> > internal to RTEMS
> > - meaning it could be any of the calls to rtems_xxx functions I am
> using.
> >
> > Please help me through the fog.
> >
> > Looking forward to your responses.
> >
> > Nick
> >
> > -----------------------------
> > Nick Thomas
> >
> >
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.com
> > http://rtems.rtems.org/mailman/listinfo/rtems-users
> >