osv at javad.com
Tue Mar 20 17:40:29 UTC 2007
"Chris Xenophontos" <cxenophontos at hammers.com> writes:
> 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.
> status = rtems_semaphore_create( "MISR", 0,
> ( RTEMS_FIFO | RTEMS_NO_INHERIT_PRIORITY | RTEMS_SIMPLE_BINARY_SEMAPHORE |
The binary semaphore could be a problem here. AFAIR, binary semaphore
maps to a core mutex(!) in RTEMS, and using a mutex from ISR context
could lead to problems. I'd try to substitute counting semaphore or
event for binary semaphore and see what happens.
 I think this is a design flaw. Binary semaphore must map to the core
semaphore with counter limited by 1.
 Mutexes are usually more restricted than semaphores. Only the thread
that locked the mutex may unlock it, so mutexes are to be used only
for mutual exclusion, not for synchronization. IMHO all the
operations on mutexes (called binary semaphore in RTEMS) from ISR
context should be explicitly prohibited.
More information about the users