jerry.needell at unh.edu
Sat Jan 26 11:58:06 CST 2008
I don't think I've been making my problem very clear. In the
application, I have several ISRS and several tasks are are to be
executed after each ISR is triggered. During initialization, all of
the tasks are started and each consists of an infinite loop that
suspends at the bottom. When an ISR triggers, it resumes the
associated task. Do you see any inherent problem with this scheme that
can lead to the error condition I am seeing? Is there a better way to
structure this? I am trying to keep it very simple.
This application has been working well for quite some time, but the
error began to occur when the highest priority task began to execute
somewhat longer than before but still far shorter than the time
between the ISRS that trigger it. Would it be of concern if the task
execution time were longer than the RTEMS Tick period?
Any suggestions are most welcome,
On Jan 25, 2008, at 5:54 PM, Joel Sherrill wrote:
> Jerry Needell wrote:
>> Thank you for the reply. I think you have hit the problem, but I'm
>> still a ways from finding it. Since my application is not using the
>> semaphore I am trying to figure out how my application can be causing
>> the problem. The task I am suspicious of is run with RTEMS_PREEMT and
>> RTEMS_INTERRUPT_LEVEL(0) set. Would you expect any from either of
>> settings? It is also the highest priority task. There application
>> well until this task is required to execute a slightly longer step
>> usual. Agin, any suggestions would be welcome.
> By definition, the priority ceiling of a semaphore/mutex is
> the priority of the most important task that will attempt
> to obtain the mutex.
> Is this a priority inheritance or priority ceiling mutex that
> is being obtained/released from an ISR? You aren't allowed
> to do that since you need a task to have priority and all
> obtains/releases of mutexes with those protocols must be
> from tasks. If this case, the priority used in the call will
> probably be that of the interrupted task.
> I have seen weird problems when this is done.
>> - Jerry
>> Till Straumann wrote:
>>> Jerry Needell wrote:
>>>> My application is entering Internal_error_Occurred from
>>>> rtems_semaphore_obtain. The call to rtems_semaphore obtain is
>>>> from internally from rtems as I am not using semaphore in my
>>>> application. I have not tracked it down yet. thin interesting point
>>>> is that in the source for rtems_semaphore_obtain, the las line is:
>>>> return RTEMS_INTERNAL_ERROR; /* unreached - only to remove
>>>> warnings */
> These are gone in the current source. There is actually no
> path to that code.
>>> This is not the only case where RTEMS_INTERNAL_ERROR
>>> is returned. The most likely cause of this type of error
>>> is a semaphore being taken from a section of code
>>> that is protected from preemption or interrupts.
>>> -- Till
>>>> but it is being reached!!
>>>> Does anyone have any suggestions for potential culprits.
>>>> BTW: I am using the sparc leon3 bsp in rtems 4.8
> Well that should be fine. :-D
>>>> - Jerry
>>>> rtems-users mailing list
>>>> rtems-users at rtems.com
>> rtems-users mailing list
>> rtems-users at rtems.com
Jerry Needell -- jerry.needell at unh.edu telephone 603 862 2732
University of New Hampshire
Space Science Center - Morse Hall
39 College Road
Durham NH 03824
More information about the rtems-users