POSIX semaphores across ISR/non-ISR contexts

[John Harwell]

Hello,

I am using the GR712RC, and due to the way the UARTs have been routed 
out on our board, we do not have access to UART0/the RTEMS console 
driver. I have therefore created my own printk() function that simply 
writes data out to another UART. Access to the debug UART is protected 
by a binary semaphore as follows:

     if (_ISR_Nest_level == 0) {
                 sem_wait(&dbg_access_sem);
     }
     uart_write(dbg_uart,(uint8_t*)proc_buf,strlen(proc_buf));
     if (_ISR_Nest_level == 0) {
             sem_post(&dbg_access_sem);
     }

     The if statements around the semaphore functions are necessary 
because if an RTEMS task is within the uart_write() call), and an 
interrupt occurs, and the ISR happens to have a debug print statement,
, then the first uart_write() call is interrupted, and the ISR debug 
statement is seen. However, after the ISR handler returns, the original 
RTEMS task is effectively dead (no more debug statements are seen, and 
no more work is done)

The guards ensure that you do not attempt semaphore related actions 
while in an ISR context. With them, my code works as expected, but I 
would like to understand why they are necessary.

How are POSIX semaphores handled when they are shared across ISR/non-ISR 
contexts, or are they not meant to be shared in that way? Why did the 
debug statement in the ISR print, even though the original RTEMS task 
had already locked the semaphore? Why is the RTEMS task unresponsive 
after the ISR returns?

All other RTEMS tasks that I have running remain active and their debug 
statements show up without issue after the ISR returns.

I am using RTEMS 4.10.

Thanks,

John Harwell
Engineer, Southwest Research Institute