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.

CC3200 OTA Wlan Connection Question

Other Parts Discussed in Thread: CC3200

I have an OTA update routine which runs in line with what is being done in the example provided by TI.  However in my OTA application I'm attempting to use the WLAN profiles to automatically allow the application to connect by simply issuing an sl_Start(0,0,0) or sl_Start(NULL, NULL, NULL) command.  Problem is when the base application has setup the connection using WPS after rebooting into my OTA app the CC3200 refuses to connect.  In fact it won't even obtain an IP address from the AP.

So I've tried adding the sl_WlanProfileGet to obtain the profile #0 information and then simply passing that on to a sl_WlanConnect.  When I do this I get a return -89 (incorrect password) error.  When this step is added an IP is acquired but there is still no connection to the AP.

Since the base application is able to reconnect with a simple sl_Start (even after re-booting out of the OTA app) I'm clueless why the OTA app can't do the same thing.  Do I need to store AP credentials somewhere and pass them to the OTA app?  Or am I missing a step in re-establishing the connection from the OTA app?  Once the base app has established connection credentials I don't want to have to re-establish them for the OTA app if at all possible.

As a side note my AP is using WPA2.  My CC3200 is the older 'HZ' version.  The sl_Start returns a 0 (ROLE_STA) which is normal.

  • Hi Craig,

    Quick questions to understand your problem better. 

    1. Do you have two application, one base application and one OTA application or these are just two OS processes

    2. If two application, the the flow is - the base application connects to AP then loads OTA application from sFlash and jumps to it. Right ?

    If CC3200 is already connected to AP when OTA application gets control it doesn't needs to re-establish the connection.

    Thanks and Regards,

    Praveen

  • Hi Praveen,

    Here is a diagram of the program flow.

    BOOTLOADER --------- (loadandexecute) --------> BASE APP

                                                                                         /

                                                                                     /

                                                                                  /

                                                                            /

                                                       (mcureset)

                                                   /

                                             /

                                       /

                                 /

                          /

                  BOOTLOADER ---------- (loadandexecute) ---------->  OTA UPDATE APP

    1)  There are 3 applications involved.

    2)  The mcureset kills the connection established in the base application.

    Note the OTA UPDATE APP will also issue an (mcureset) which will invoke the BOOTLOADER which will issue a (loadandexecute) to return to the BASE APP.  When it does this the BASE APP reconnects with the sl_Start without any problems.

    I'm also aware the OTA update library states it isn't compatible with the older chipsets.  I'll be using the bootloader process to invoke an OTA update which uses a proprietary process but will not be using the supplied API to download any updates.

    Also the BASE APP uses TI-RTOS while the BOOTLOADER & OTA UPDATE APP do not use a multi threaded OS.  So it could be I'm just not doing something correctly in a NON-OS environment.  In the OTA UPDATE APP I issue the sl_Start and go into a 30 second while loop looking for "g_ulStatus" to show IS_CONNECTED and IS_AP_ACQUIRED with 1 second intervals in the loop.

  • Well looking at the reference application I may have just answered my own question.  I need to use the _SlNonOsMainLoopTask in a way that's consistent with the example.  Let me try this and I'll let you know if that corrects the issue.

  • I think the _SlNonOSMainLoopTask call was the issue.  I had a 1 second delay between calls and when removed it started connecting.  As a result I think I'll adopt an approach closer to the reference application.