CC3200-LAUNCHXL: CC3200 stucks at sl_FsOpen() and prvTaskExitError()

// code related to this question in http server
void SimpleLinkHttpServerCallback(SlHttpServerEvent_t *pSlHttpServerEvent,
                               SlHttpServerResponse_t *pSlHttpServerResponse)
{
    unsigned char strLenVal = 0;
    int i;
    
    if(!pSlHttpServerEvent || !pSlHttpServerResponse)
    {
        return;
    }
    switch (pSlHttpServerEvent->Event)
    {
        case SL_NETAPP_HTTPPOSTTOKENVALUE_EVENT:
        {
          unsigned char *ptrName = pSlHttpServerEvent->EventData.httpPostData.token_name.data;
          long lenName = pSlHttpServerEvent->EventData.httpPostData.token_name.len;
          unsigned char *ptrValue = pSlHttpServerEvent->EventData.httpPostData.token_value.data;
          long lenValue = pSlHttpServerEvent->EventData.httpPostData.token_value.len;

          
          if(IS_TOKEN_MATCH(ptrName, PUSH_START_TOKEN)){ // push starts
            // atomic
            osi_LockObjLock(&pushLock, OSI_WAIT_FOREVER);
            memcpy(pushMsg.msg, ptrValue, lenValue);
            (pushMsg.msg)[lenValue] = '\0';
            pushMsg.msgLen = lenValue;
            pushMsg.op = STORAGE_OP_OPEN_WRITE;
            osi_LockObjUnlock(&pushLock);
            // atomic
            osi_SyncObjSignalFromISR(&pushSync);
          }
        }
          break;
        default:
          break;
    }
}

// code related to file operation task
while(osi_SyncObjWait(pMsg->pSync, OSI_WAIT_FOREVER) == OSI_OK){
        osi_LockObjLock(pMsg->pLock, OSI_WAIT_FOREVER);

        lRetVal = 0;

        switch (pMsg->op)
        {
            case STORAGE_OP_OPEN_WRITE:
                lRetVal = appCreateFile(pMsg);
                break;
            default:
                break;
        }
        if(lRetVal < 0){
            ERR_PRINT(lRetVal);
        }
        osi_LockObjUnlock(pMsg->pLock);
}

Sorry, code is here. I don't know why my code was gone.

figure of call stack.

long appCreateFile(StorageMsg_t *pMsg)
{
    long lRetVal = -1;

    strcpy(pMsg->pFile->filename, pMsg->msg);

    lRetVal = sl_FsOpen((unsigned char*)pMsg->msg,
        FS_MODE_OPEN_CREATE(OPEN_FILE_SIZE, 
            // _FS_FILE_OPEN_FLAG_COMMIT | _FS_FILE_PUBLIC_WRITE),
            _FS_FILE_OPEN_FLAG_COMMIT),
        &(pMsg->pFile->token),
        &(pMsg->pFile->fileHandle)
    );
    if(lRetVal < 0){
        UART_PRINT("%s already created\n\r", pMsg->msg);
        lRetVal = sl_FsClose(pMsg->pFile->fileHandle, 0, 0, 0);
        ASSERT_ON_ERROR(FILE_ALREADY_EXIST);
    }
    else{
        UART_PRINT("%s created\n\r", pMsg->msg);
        lRetVal = sl_FsClose(pMsg->pFile->fileHandle, 0, 0, 0);
        ASSERT_ON_ERROR(lRetVal);
    }

    return lRetVal;
}

implementation of appCreateFile()

Hi,

There isn't any requirement to using sl_FsOpen() other than having called sl_Start() to init the NWP of the CC3200.

Are trying to call sl_FsOpen() in an ISR context? That is not allowed on the CC3200 host driver, in fact you cannot call any sl_*() API from an ISR context on the CC3200.

Regards,

Michael

No, what I did is to let httpServerCallback() calls osiSyncObjSignalFromISR(), and there is one osi_task waiting to be signaled thus perform sl_*() operations.

I write in this way because I've read about other articles talking about sl_Fs*() under the framework of FreeRTOS(osi.h).

I'm sure that I'm not calling any sl_*() API in any ISR but cc3200 still hangs at sl_FsOpen().

Any possible reason for hanging at sl_*() ?

Thank you for your reply !

Hi,

If you are not calling any simplelink APIs in an ISR context, then there isn't an easy explanation for why you get that hang at sl_FsOpen(). Are you ensuring that sl_Task() can run? Sometimes in threaded applications sl_Task() can be continuously preempted and never run.

If sl_Task() isn't the cause, then please collect the NWP logs from the device. This will allow me to see the state of the NWP as this hang occurs. You can find instructions on how to do so here: https://processors.wiki.ti.com/index.php/CC3100_%26_CC3200_Capture_NWP_Logs

Regards,

Michael