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.

CC3235SF: Stuck after entering in provisioning mode with country code set to World Wide ("00")

Part Number: CC3235SF
Other Parts Discussed in Thread: UNIFLASH

So, as the title stated, our application stuck in a power on -> boot -> call sl_Start -> reset"   loop. This happen if I power off the board while in provisioning state. In previous versions of the code, this behavior do not occurs. I could track this behavior and it started after I add a call to set country code, setting to "00". If a set to "BR" (Brazil, where I am), the code do not stuck if I reset while in provisioning mode. Am I doing something wrong? Could you try to reproduce that? I am currently using SDK 3.30.01.02, with service pack "sp_4.10.0.1_3.7.0.1_3.1.0.26".

_u8  Str[] = "00";
Status = sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, SL_WLAN_GENERAL_PARAM_OPT_COUNTRY_CODE, 2, Str);
if( Status )
{  
    UART_PRINT("Failed set AP Country. Error: %d\n\r", Status);
}


The return error from sl_Start is -2005 (SL_API_ABORTED), caused by a timeout event, 1 minute after the call. After that, the code currently call "ProcessRestartMcu", so that is why we enter in a loop continuously reseting.

Thank you

  • Hi Elder Tramontin,

    Do you have 5 GHz enabled, and do you start provisioning in station or AP mode? Do you see the issue using the provisioning example from the SDK so I can replicate?

    Best regards,

    Sarah

  • Hi Sarah,

    Thank you for your response. I have 5 GHz enabled. I will try the provisioning example and keep you update, but I can't do this until monday.

    Best regards,

    Elder

  • Hi Sarah,

    I was able to reproduce this behavior with provisioning example  (ti/simplelink_cc32xx_sdk_3_30_01_02/examples/rtos/CC3235SF_LAUNCHXL/demos/provisioning/tirtos/ccs) from Simplelink 3.30.01.02. The only modification needed was add the following lines to provisioning.c at line 1647, after sl_Start() call:


        if ( (SECURED_AP_ENABLE) || (status != SECURED_AP_ENABLE))
        /*Will enter only if previous and present Secure AP are different or Secure AP is 1*/ 
        {
            SetSecuredAP(SECURED_AP_ENABLE);
            if (ROLE_AP == gRole)
            {
                /* Reset device to start secured AP */
                sl_Stop(SL_STOP_TIMEOUT);
                gRole = sl_Start(NULL, NULL, NULL);
            }
        }
    
    //  -----------------  new: ------------------------
        _i16 Status;
        _u8  Str[] = "00";
        Status = sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, SL_WLAN_GENERAL_PARAM_OPT_COUNTRY_CODE, 2, Str);
        if( Status )
        {
            UART_PRINT("Failed set AP Country. Error: %d\n\r", Status);
        }


    I used Uniflash 6.3, with "cc3235sf_out_of_box_tirtos" project also from sdk 3.30.1.2. If change the line "00" to other country as "EU", "BR", "JP", the code works. Otherwise, the code start for the first time as expected, but if you power down or reset, the second time will stuck while calling sl_Start.


    Something odd that I saw this time on Uniflash was searching "WorldWide" in "Country Code" field under Uniflash "Advanced>System Setting>Role Settings>General Settings". The Code returned was "WW", differing from "00" stated in SWRU455's Appendix C. I think this difference is just in the user's view, and internally the code is configured correctly, but I think it's worth mentioning. Anyway, after seeing this I changed code in provisioning.c to try to use "WW", but this code returns "SL_ERROR_WLAN_INVALID_COUNTRY_CODE" error.

    Please tell me if I need to provide more information about how to reproduce this behavior. Thank you!

    Best regards,
    Elder.

  • Hi Elder,

    To clarify, sl_Start() only hangs if you reset during provisioning?

    Can you test this on your setup with the provisioning example from the latest CC32xx SDK? This will help determine if the issue is in the host driver. If you see the same issue on the latest SDK, please capture NWP logs (see section 20.1 of the NWP guide).

    Best regards,

    Sarah