rtems_semaphore_obtain

[Chris Xenophontos]

All, thanks for the suggestions-

The interrupt is a continuous interrupt source, does not need re-enabling.
It is ack'ed in the ISR upon entry, and the H/W regs are being loaded into
global variables.

Almost appears to be a point at which, during execution of the task, that
release of a semaphore does not register.  Again, this is once in about 4-10
hours, with interrupt being generated every 3.001 seconds.

I am going to start with a simple fix first, i.e, using a counting
semaphore, as L. Pollak indicated - 

Then we'll look into other more involved solutions

thanks
Chris Xenophontos



-----Original Message-----
From: Eric Norum [mailto:norume at aps.anl.gov] 
Sent: Monday, March 19, 2007 12:45 PM
To: Chris Xenophontos
Cc: rtems-users at rtems.org; 'Tom Phillips'
Subject: Re: rtems_semaphore_obtain

Does your hardware interrupt continuously or does the awakened task  
have to do something to reenable the hardware?

Although you don't say it, I presume that you are now using some sort  
of global variable to communicate the three values read from hardware  
from the ISR to the task.

How about changing the ISR from using a semaphore to using a message  
queue to send the three values to the task?   This is more robust  
since no data are lost should the task not be able to keep up for a  
brief period because of higher priority tasks in the way.


On Mar 19, 2007, at 11:31 AM, Chris Xenophontos wrote:

>
> Correction,
>
> example is incorrect, myIsrSemId is passed as an rtems_id, not as a  
> pointer,
>
>
> thanks Eric,
> cx
>
>
> -----Original Message-----
> From: Eric Norum [mailto:norume at aps.anl.gov]
> Sent: Monday, March 19, 2007 11:47 AM
> To: Chris Xenophontos
> Cc: rtems-users at rtems.org; 'Tom Phillips'
> Subject: Re: rtems_semaphore_obtain
>
> If that's really an accurate description of the code I'm amazed that
> it works at all.
> rtems_semaphore_obtain and rtems_semaphore_release take an rtems_id
> as their first argument.  They do not take a pointer to an rtems_id
> as you have shown.
>
> On Mar 19, 2007, at 9:39 AM, Chris Xenophontos wrote:
>
>> Hello all,
>>
>> We have a situation, running RTEMS 4.6.0, on a Coldfire 5208.
>> One of the threads (tasks) in our application pends with a one-second
>> timeout on a semaphore released by an ISR.
>>
>> The interrupt source that triggers the ISR (for this test case)
>> runs every 3
>> seconds (~3.011).  This re-creates the problem more frequently.
>>
>> Typically, the task will run, timeout once per second, unless the
>> ISR is
>> triggered, in which case it will recognize it and process
>> accordingly.  The
>> task processes critical values read from hardware that are latched
>> by the
>> ISR.  99.99% of the time, it works as expected.
>>
>> As the ISR trigger "walks" close to the time of task timeout, we
>> see the
>> back-to-back executions, as expected.
>>
>> However, every 10 hours or so, the task will not respond to the
>> semaphore
>> released from the ISR, even though debugging clearly shows the ISR
>> responded
>> to the HW interrupt and latched the hardware values.
>>
>> The effect is a dropped interrupt - the rtems_semaphore_obtain call
>> does not
>> return with an RTEMS_SUCCESSFUL status -- it returns a TIMEOUT.  No
>> other
>> RTEMS error status are returned either (we check for these well).
>>
>> The task, ISR, and semaphore_create function that we're using are
>> listed
>> below.  Any help appreciated!!
>>
>> Thanks
>> Chris Xenophontos
>>
>> ///////////// mytask//////////////////
>> mytask()
>> {
>>     while( 1 )
>>     {
>>     rtems_status = rtems_semaphore_obtain( &myIsrSemId,
>>                                             RTEMS_WAIT,
>>                                             100 );  // 100 ticks =
>> 1 second
>>
>>     if(( rtems_status != RTEMS_SUCCESSFUL ) &&
>>        ( rtems_ststaus != RTEMS_TIMEOUT   ))
>>     {
>>        // post error status ( we NEVER see an error here )
>>     }
>>
>>     if( rtems_status == RTEMS_SUCCESSFUL )
>>     {
>>         // do specific processing based on semaphore released by ISR
>>         ( not always seen, even though the ISR ran)
>>     }
>>     else
>>     {
>>         // specific processing based on timeout waiting for semaphore
>>     }
>>     }
>> }
>> //////////////// end mytask///////////
>>
>> the ISR is as follows
>> ///////////////////myIsr////////////////
>> myIsr()
>> {
>>     ( code to ack the Colfire interrupt )...
>>
>>     code to read 3 hardware registers....
>>
>>     rtems_semaphore_release( &myIsrSemId );
>> }
>> ///////////////myIsr///////////////////
>>
>> the semaphore is created as follows, and is always created
>> succesfully:
>>
>> status = rtems_semaphore_create( "MISR",  0,
>> ( RTEMS_FIFO | RTEMS_NO_INHERIT_PRIORITY |
>> RTEMS_SIMPLE_BINARY_SEMAPHORE |
>> RTEMS_NO_PRIORITY_CEILING | RTEMS_LOCAL ),
>> RTEMS_NO_PRIORITY, &myIsrSemId )
>>
>>
>> mytask is created with the following attributes:
>> RTEMS_PREEMPT | RTEMS_NO_ASR | RTEMS_NO_TIMESLICE |
>> RTEMS_INTERRUPT_LEVEL(0),
>> RTEMS_FLOATING_POINT | RTEMS_LOCAL,
>>
>> thanks,cx
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>
> -- 
>
> Eric Norum <norume at aps.anl.gov>
> Advanced Photon Source
> Argonne National Laboratory
> (630) 252-4793

-- 

Eric Norum <norume at aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793