• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 39 subscribers
  • Views 411 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3120: Mutex implementation in porting layer

Bear Chen
Prodigy 70 points
Part Number: CC3120

There is a confusing implementation in the porting layer of CC3120. Based on the SDK's demo (with MSP432), in user.h, it says

#define sl_LockObjLock(pLockObj,Timeout)          Mutex_lock(*(pLockObj))

which ignores the Timeout parameters. Also, in cc_pal.c, the Mutex_lock points to MutexP_freertos.c, which says:

uintptr_t MutexP_lock(MutexP_Handle handle)
{
    SemaphoreHandle_t xMutex = (SemaphoreHandle_t)handle;

    /* Retry every 10 ticks */
    while (xSemaphoreTakeRecursive(xMutex, (TickType_t)10) == pdFALSE) {
        ;
    }

    return (0);
}

Overall, the implementation effectively force the caller to wait forever and ignore the timeout parameter, even the caller want it to return immediately. Is there any specific reason by doing so?

  • 0
    TI__Expert 8255 points
    Hi Bear,

    You are correct, the SimpleLink host driver does not use the timeout parameter in the code you referenced above. That is not to say that in your application you must also ignore the timeout parameter. If you wanted to include the timeout in your application code, then you could do this using the POSIX layer/RTOS function for object lock.
  • 0 in reply to Austin Tanner
    Prodigy 70 points
    Hi Austin,
    Thanks for your reply, but that does not answer my question. My question is that if there are any specific reasons for ignoring the timeout parameter in your MSP432 implementation?
    I think the point here is not whether I want to include the timeout in my code or not, it is more like why you ignoring it in the MSP432 reference implementation. If the timeout parameter is not important, then why it is there? And if the timeout parameter is important, why your (TI) official MSP432 reference implementation does not honour it without any reasons? However, the SLStudio (Windows) port does implement timeout appropriately.
  • 0 in reply to Bear Chen
    TI__Expert 8255 points

    Hi Bear,

    I am not aware of the exact reason why the timeout parameter is not used in the host driver. If you take a look at references to sl_LockObjLock in the host driver, you'll see the timeout parameter is set to SL_OS_WAIT_FOREVER. So, my guess is that this parameter was never critical to the driver function.

    I'll get back to you with a follow up if there is any significant reason as to why it is not used.

  • 0 in reply to Bear Chen
    TI__Expert 8255 points
    I did receive an update and was told this was just a timeout that remained from old code. There is a task to remove it. Please ignore the parameter.