CC3220SF: Provisioning Forcing Program into FaultISR

Hi Brian,

For any hard fault, a useful debug tool is the RTOS object viewer. This is a CCS tool that can query and display information from the TIRTOS instance running on the CC3220. See my instructions in this post to launch the ROV tool: https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/733294/2707429#2707429

Once you have entered the hard fault and have launched the ROV tool, you can check the RTOS state and see if there is any obvious cause of the hard fault. I would check the state of the heap and well as the stacks for each thread you have, as memory overflows are a very common cause of hard faults.

Let me know if you find anything unusual in the ROV tool.

Regards,

Michael

Hi Michael, I'm having trouble launching the ROV Tool, and I'm not quite sure what I should be adding in my preferences to allow me to use it. Not sure how important it is but I'm using the FreeRTOS version of the project.

Anything I'm finding about it wants me to add something here but I'm not quite sure what that is exactly.

Hi Brian,

The ROV tool only works with TIRTOS, and not FreeRTOS.

I suggest you either move to a TIRTOS project, or look into third-party debug solutions for FreeRTOS. There are also some built-in hooks that you can use with FreeRTOS to catch certain error events such as stack overflow events. See my post here for details: https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/773264/2863066#2863066

Regards,

Michael

Hi Michael,

Changing the project to run with TI-RTOS as opposed to FreeRTOS is something that I'd rather avoid for now. I've isolated that having a specific function running inside a thread that I create is determining whether the FaultISR is tripped. With the function in the thread the FaultISR trips. With the function commented out, the program runs normally. I've added my code for that one function below. Is there something I'm missing that would cause the fault to trigger? I've tried increasing the stack size of the thread that calls this function with no success.

void httpPostTask() {
    LOG_MESSAGE("HTTP Task Started\r\n");
    static bool isFirstTaskRun = true;

    /* Initialize Timer if needed */
    if(isFirstTaskRun){
        httpPost_TimerInit();
        isFirstTaskRun = false;
    }

    SP_ResetSample(spiData);    // Reset AFE Sample Data
    
    /* Print to the Display */
    SH1106_ClearScreen();
    SH1106_Print_Row(0, " Application Running ");

    /*
     *  If timerFlag has been set, it is time to post to the server. If not posting,
     *  continue reading AFE Channel data.
     */
    while(1){
        /* If paused, delay so other threads can run */
        if(applicationPaused){
            vTaskDelay(1);
        }
        else{
            /* If timerFlag is set, post data to server then reset flag */
            if(timerFlag){
                httpSendPost();
            }

            /* If screenFlag is set, update display and reset flag */
            if(screenFlag){
                SH1106_Print_Row(2, timerBuf);
                SP_UpdateScreen();
                SP_ResetScreenAccumulator();
                screenFlag = false;
            }

            /* AFE Channel Readings */
            AFE_ReadChannels(spiData);
        }
    }
}

Hi Brian,

If you have narrowed down the cause of the fault to the httpPostTask(), I suggest that you use the debugger to single-step through that function and see which exact line of code causes you to entire the faultISR. Knowing exactly where the fault occurs would make this issue much simpler to debug.

Let me know once you have found where the fault occurs in your program.

Regards,

Michael

Hi Michael, 

I've changed up my code a bit since I last posted. Instead of being ran from a separate thread, the httpPostTask function has replaced the SendPingToGW function in the state machine that controls the provisioning task. Also, instead of the while(1) loop, it is a while(!applicationPaused). However, my httpPostTask function does not appear to be what is tripping the faultISR. The program enters the faultISR after the call of mq_receive() that runs inside the while(1) loop of the ProvisioningTask. I haven't been able to isolate any cause further than that.

Hi Brian,

If the program is entering the faultISR at mq_receive(), then I would step into that function to see precisely where the faultISR is occurring. Maybe it could be due to a bad pointer being passed into the mq_receive() function.

Regards,

Michael