Semaphore_pend not returning

HI William,

What target are you using?

Semaphores_pend() block when the count == 0. The count value should in the ISR should be 0 before you perform a Semaphore_post().

What's your Semaphore starting value? I think you want it to be 0.

Tom,

We are using the AM3352.  I start with the count at 0 and in my interrupt routine post the semaphore.

Yesterday I conducted another test to see if setting the semaphore a second time would release the semaphore.  It did not.  I also checked the task running during the interrupt and it was the task pending the semaphore.

Looking at the code for the semaphore_pend it appears there is a portion of the code which will shut off scheduling in sysbios.   It seems like scheduling was never reenabled.  Is there a way I can tell if the scheduler is shut off?

Bill,

On which core are you running this? Does the Swi Example work? Can you post your .cfg and you .c file?

William Kozlowski said:

I can make the problem go away by inserting a small delay between starting the USB and setting up the Pend.  This would allow the Post to completely occur before the Pend gets started.  The larger messages would take longer the finish so the small delay will still allow the Pend to be setup before the USB could complete, therefore the Post would happen after the task is in a pending state.

Doing this just means that the Task isn't being put into a blocked state (as the Semaphore has already been posted). If interrupts are disabled, that will prevent the scheduler from switching to next highest ready Task.

In ROV, you can check the Clock -> Module tab and see if the ticks are incrementing ~10000 ticks if you let it run for ~10s between halting the core. There is also the Hwi view, which has a "Detailed" tab that can tell you if the interrupt for the Timer driving the system tick is enabled. (It should be enabled)

If you are using the BIOS.LibType = LibType_Instrumented, you should also be able to look at the Logs and see how your Semaphores are being incremented/decremented.

Are you calling a Task_disable() without a Task_restore()? Or a Hwi_disable() without a Hwi_restore()?

Tom,

This code is running in our actual product and not on a development board.  It is part of a much larger program.  We have very good tracing capabilities with timing information.

The majority of time the code works fine.  We have found a particular PC which on occasion causes this issue.  I believe it is a timing issue.  Our USB code is based on the Starterware code.  I just realized the starterware code (version 5)  will lock up in a HWI for extended periods of time (25MS) waiting for a USB transaction to complete.  I will be moving this code out of the interrupt routine shortly.  Hopefully this is part of the issue.

The clock is still advancing since interrupts are still working and I'm reading the tick count and it's incrementing.  The semphore has also been incremented.  In this interrupt routine I check to see which task is running and it indicates it is the task which should be waiting for the semaphore.

I believe there has been a task_disable and therefore no other task will operate.

By the way I tried to replace the semaphore post with a message to another task which would then do a semaphore_post.  This message never reaches the task so therefore I believe we are locked into the currently running task.

I never call task_disable.  The operating system seems to in Semaphore_pend.

I've just looked at the code for the Task_restore function

/*
 *  ======== Task_restore ========
 */
Void Task_restore(UInt tskKey)
{
    if (tskKey == FALSE) {
        Hwi_disable();
        if (Task_module->workFlag
            && (!BIOS_swiEnabled || (BIOS_swiEnabled && Swi_enabled()))) {
            Task_schedule();
        }
        Task_module->locked = FALSE;
        Hwi_enable();
    }
}

Shouldn't the Hwi_disable() and Hwi_enable be storing a key at this point.  If interrupts are disable coming into a Task_restore they will not be coming out.

Bill,

Sorry for the long wait. I'm waiting to hear back from our local SYS/BIOS kernel expert.

Is the semaphore issue happening to just this particular semaphore instance or to all semaphores in your system? Was it created statically or dynamically? Have you gotten around to try ROV at all? Can you use instrumented BIOS libraries (or custom libraries with Asserts enabled)?

Bill,

From the description, it does sound like Semaphore_pend() was called with the Task or Swi scheduler already disabled.

When that happens, the task will NOT block on the Semaphore as it should and the internal Task scheduling state variables become corrupted.

In 6.35.00 and newer versions of SYS/BIOS we put an Assert in Semaphore_pend() to check for this condition as this issue has come up before.

A common way for this situation to occur is if your application explicitly calls Task_disable() or Swi_disable() and then calls Semaphore_pend() before calling Task_restore() or Swi_restore().

A more subtle way for this to occur is if your application uses a GateSwi or GateTask to arbitrate access to a resource. These Gates are wrappers for Task_disable() and Swi_disable(). Calling Semaphore_pend() after GateTask_enter() or GateSwi_enter() is usually fatal.

Another thought: are you sure that the Semaphore is not being posted faster than the task can process the associated work?

Alan