BDI-2000 was Re: Internal_errors_What_happened = 18? (RTEMS_CALLED_FROM_ISR)

[Joel Sherrill]

Nick Thomas wrote:
>   
>> -----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 o 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!
>   

If I remember this all correctly, the BDI-2000 speaks regular
gdb remote protocol.  You can use the powerpc-rtems gdb
binary and connect something like this:

target remote IP:PORT


You might want to do a "load" command to get the image
to the target.

But this should be in your bdi documentation.  Perhaps someone
with one currently setup can be of more direct use.

Then you can use the gdb "bt" command.
> 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
>>>
>>>       
>
>