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.

Compiler/CC3220SF-LAUNCHXL: issue while rebooting device in provisioning

Part Number: CC3220SF-LAUNCHXL

Tool/software: TI C/C++ Compiler

Hi,

1. If any Power on reset occurs to the device, initiating the provisioning start process (Even profile exist).

2. I am setting 3 minutes timeout for provisioning process.  Upon timeout, if old profile exist validate and continue to connect to the router. If new profile added continue with the new profile.

3. During provisioning (state is in provisioning in progress ), if something wrong(mostly with custom mobile app delays), if validate link connection also fails, i am trying to rebooting the device. This operation is not giving expected result. 

4. Even I performed reboot (this API contains sl_Stop) , NWP is not getting reset and any further operations of NWP after reset is returning -2014L(SL_RET_CODE_PROVISIONING_IN_PROGRESS ).

Please find the following code to reset the device.

    if (wakeupSource == PRCM_POWER_ON && (NetworkGetIndicate == true))
    {
        local_provisioning = true;

        if (IotSemaphore_TimedWait(&Provisioning_ControlBlock.provisioningDoneSignal,
                            LOCAL_AP_CONN_PROVISION_TIMEOUT) == false)
        {  
            IotLogInfo("[local Provisioning] semaphore wait timeout occurred, connecting with existing WIFI Network profile\n\r");

            if(validateLocalLinkConnection(&deviceRole) != 0)
            {
                IotLogInfo("[local Provisioning] something went wrong rebooting device\n\r");
                mcuReboot();
            }
        }
    }

void mcuReboot(void)
{
    // Set the burst mode for PM before reset
    Board_setBurstMode();

    /* stop network processor activities before reseting the MCU */
    sl_Stop(SL_STOP_TIMEOUT);
    IotLogInfo("[RSESET] Restart immediately\r\n");

    usleep(SLEEP_BEF_HIB_RESET);

    /* Reset the MCU in order to test the bundle */
    PRCMHibernateCycleTrigger();
}

Please find the debug trace for more info

60 184602 [pthread] [INFO ][DEMO][184602] [WLAN EVENT] IP address acquired
Error [-2014] at line [1299] in function [validateLocalLinkConnection]
61 189388 [iot_thread] [INFO ][DEMO][189388] [local Provisioning] semaphore wait timeout occurred, connecting with existing WIFI Network profile

62 189395 [iot_thread] [INFO ][DEMO][189395] [local Provisioning] something went wrong rebooting device

63 189396 [iot_thread] [INFO ][DEMO][189395] [POWER MANAGER] SET TO BURST MODE.

64 189426 [iot_thread] [INFO ][DEMO][189426] [RSESET] Restart immediately

0 1001 [Tmr Svc] [INFO ][DEMO][1001] OTA demo version 1.0.0

1 1001 [Tmr Svc] Simple Link task created
2 1146 [Tmr Svc] [INFO ][DEMO][1146] Device came up in Station mode
3 1146 [Tmr Svc] [prvPAL_GetPlatformImageState] sl_FsGetInfo failed (-2014) on /sys/mcuflashimg.bin

5. Is there any specific way to reset NWP? the above reboot API impacts only on Host processor? 

Note: I am using Hibernate feature with RAM retention changes, is this settings will impact reboot? Please help me out.

  • You will need to stop the provisioning before the NWP reset. As long as the provisioning is enabled you can't call other sl commands (and the provisioning state is maintained during reset).

    Please call the stop command:

    sl_WlanProvisioning(SL_WLAN_PROVISIONING_CMD_STOP,0xFF,0,NULL, 0x0);

    And then wait for SL_WLAN_EVENT_PROVISIONING_STATUS / SL_WLAN_PROVISIONING_STOPPED wlan event (in SimplelinkWlanEventHandler).

    Only upon the provisioning stop indication, you should reset the NWP. 

    I'm not sure about your logic. The typical one starts by waiting (for couple of seconds) for the store profile to try to connect and only in case of failure (timeout) it goes to provisioning. The suggested logic can introduce long delay in the usual case where the old configuration is good.

    How do you detect a mobile app delay? The provisioning idle timeout is supposed to take care of this.

    Br,

    Kobi