Forums

Hi E2Er's

We are working on OMAPL138 and have a low priority task which passes information (approx 42 Uint32's) from DSP->ARM every 1 second as follows


LOWEST PRIORITY TASK
{
    while(1)
    {
    TSK_sleep(1000);
    if(MSGQ_INVALIDMSGQ != gppQueueForLog)
    {
        msgqStatus = POOL_alloc () ;                
        if (msgqStatus != SYS_OK)
        {
            continue;        
        }
    
        msgqStatus = MSGQ_alloc();
        if (msgqStatus != SYS_OK)
        {      
            POOL_free();
            continue;    
        }
        else
        {
            memcpy();        
            HAL_cacheWbInv();

            MSGQ_setMsgId();                                        
            msgqStatus = MSGQ_put();
            if (msgqStatus != SYS_OK)
            {
                POOL_free();
                MSGQ_free();    
            }
            else
            {
                // POOL_free() from ARM side in response to message           
            }
        }    
    }    
    }
}

What we are finding is that if we start getting POOL_alloc failures our higher priority Tasks appear to be starved of CPU time ? The other tasks do not rely on any of the information or processing of this low priority task (it's a built on test thread).

If we run our application without this thread all is well. If we increase TSK_sleep(1000) to TSK_sleep(3000) again all is well.

We don't understand how the higher priority tasks are being starved here?

Is POOL_alloc() somehow blocking out the other higher pririty tasks when we are waiting for msgqStatus ? Any other ideas welcome.

BR

Barry