• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 40 subscribers
  • Views 1119 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3000 Sensor Application Smart Config Failure with WPA2 Access Point?

Craig Heilman
Intellectual 310 points
Other Parts Discussed in Thread: MSP430FR5739

I'm having problems getting SmartConfig to work with the CC3000 (Murata VK) + MSP430FR5739 kit (CC3000FRAMEMK-M) on a password protected (WPA2-personal) network. I was able to successfully use SmartConfig to get the eval board connected to an open network (TP-Link access point) and run the Sensor Application "planet" demo.

Background:

  • CC3000 has been updated to latest SP (1.13)
  • first testing was with Sensor Application binary that was packaged with SP 1.10.1
  • subsequent testing has been with a new Sensor Application built from source with CCS 5.5 in order to use the debugger

What works:

- open network, TP-Link access point at 192.168.1.1, SmartConfig application run on iPhone (iOS 7.1.1) connected to the TP-Link network

What doesn't work:

- WPA2-personal protected network, Apple Airport Extreme access point at 10.0.1.1, SmartConfig application run on iPhone which is connected to the Apple Airport network, WPA2 password entered

When I press the S1 button on the MSP430 board, the code does enter StartSmartConfig() and ends up sitting in the while (ulSmartConfigFinished == 0) { } loop waiting for the process to finish. In the successful case, I receive the HCI_EVNT_WLAN_ASYNC_SIMPLE_CONFIG_DONE event in CC3000_UsynchCallback(). In the unsuccessful case, I never see that event from the CC3000.

I don't know if the issue has to do with the IP numbers (192.168.1.x vs 10.0.1.x) or the security (none vs WPA2) or other?

Any suggestions?

  • 0
    TI__Mastermind 27095 points

    Hi Craig,

    The smartConfig does work with 1.13 for APs secured with WPA2. And it works with IP address series 10.0.1.x as well. Can you please confirm if you have migrated the host driver that comes with 1.12 release package (Relase 1.13 comes only with the Service Pack)?

    And also, it depends on the connection that your configuration device sets up with the AP. SmartConfig is not supported over any connection over MIMO or SISO-40MHz. Please refer to the smartConfig limitations here: http://processors.wiki.ti.com/index.php/CC3000_Smart_Config#Limitations

    Thanks & Regards,
    Raghavendra

  • 0 in reply to Raghavendra Shenoy
    Intellectual 310 points

    Raghavendra Shenoy Mathav said:

    The smartConfig does work with 1.13 for APs secured with WPA2. And it works with IP address series 10.0.1.x as well. Can you please confirm if you have migrated the host driver that comes with 1.12 release package (Relase 1.13 comes only with the Service Pack)?

    What do you mean by the term "migrated"? I simply used the Patch Programmer under CCS 5.5 per the instructions (http://processors.wiki.ti.com/index.php/CC3000_Patch_Programmer), first installing the firmware included with "Patch Programmer Utility" version 1.12, then the firmware from version 1.13, both downloaded from http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_Downloads. I did NOT install the SDK 1.12 (i.e. the "Basic Wifi Application") from that same page as I'm using the "Sensor Application" from SP 1.10.2. I saw the message at the top of the release notes:

    Please note it is a MUST to upgrade both CC3000 patches and Host Driver when upgrading from versions lower than V1.13.

    The release package 1.13 will contain only the Service Pack update. This Service Pack should be used with the Host Driver that is part of the release package 1.12.

    but it's unclear what exactly that note means. If one needs to actually copy some host driver code from one location to another, that should be stated explicitly in the release notes (http://processors.wiki.ti.com/index.php/CC3000_Release_Notes). I assumed that was NOT the case because the release package 1.13 (which expands to the directory: PatchProgrammerMSP430FR5739-1.13.7.15.28) includes a "CC3000HostDriver" directory that contains source and object files. What am I missing here???

    Raghavendra Shenoy Mathav said:

    And also, it depends on the connection that your configuration device sets up with the AP. SmartConfig is not supported over any connection over MIMO or SISO-40MHz. Please refer to the smartConfig limitations here: http://processors.wiki.ti.com/index.php/CC3000_Smart_Config#Limitations

    Ok, so I reviewed the limitations. The Apple Airport Extreme router does support MIMO (don't know about SISO-40MHz). The only configuration option I can change that may affect whether MIMO or SISO-40MHz are used is an option to select the radio mode. The options are:

    • 802.11a/n - 802.11b/g/n (Automatic)
    • 802.11a/n - 802.11b/g
    • 802.11a - 802.11b/g

    I had the first option selected so I tried the other two.

    With option 802.11a/n - 802.11b/g selected, the CC3000 did exit the SmartConfig mode because LED6 did stop blinking and then LEDs 1-4 and 6 lit up but the SmartConfig application on the iPhone never finishes and I do not see the CC3000 show up in the router's DHCP client table. I didn't attempt to trace the code beyond confirming that the ulSmartConfigFinished flag is indeed being set.

    I then tried the 802.11a - 802.11b/g setting and got the same results as above. If I break into the debugger after the LEDs have lit up, it always seems to break at IntSpiGPIOHandler() in spi.c. I don't know if that is significant?

    If I go back to the original demo kit setup and have the CC3000 connect to the TP-Link router, can I then bridge that TP-Link network (and the CC3000) over to my regular office network via the Windows 7 computer? Keep in mind the end goal of all this is to have the CC3000 send an email (following the SMTP demo) to a computer out on the Internet!

    Here's a simplified connection diagram of what I have in mind:

    CC3000 <- wifi -> TP-Link (192.168.0.1) <- ethernet -> Windows 7 Pro PC <- wifi -> Apple Airport Extreme router (10.0.1.1) <- Internet

    Thanks,

    Craig

  • 0 in reply to Craig Heilman
    Expert 1140 points

    Hi Craig,
    >but it's unclear what exactly that note means
    In the source tree you have a folder called "CC3000HostDriver". To "upgrade" the host driver, you just replace (copy->paste and overwrite) the files in this folder with "fresh" ones from the new SDK.

    Cheers,
    Risto

  • 0 in reply to Risto Koiva
    TI__Mastermind 27095 points

    Hi Craig,

    Moving to latest host driver means replacing the existing CC3000HostDriver folder with the one that comes with the latest host driver release package. In your case, the host driver folder CC3000HostDriver in the latest patch programmer source will contain the latest host driver.

    Regarding the smartConfig, it looks like you have passed the stage of smartConfig process. You should now have the details of the AP(SSID + security key) at the CC3000. The smartConfig application on the phone will continue to run even after the process is complete. Now, only the process of connection is not going through. Following are the reasons that I could think of:

    1. If you are using the encryption key, make sure that 'CC3000_UNENCRYPTED_SMART_CONFIG' is not defined.

    2. If you are using the smartConfig with encryption, you should make sure that wlan_smart_config_start is passed an argument '1'. (i.e, wlan_smart_config_start(1)). If not, then use wlan_smart_config_start(0)

    3. Make sure that correct AES encryption key is used, both in the smartConfig application and at CC3000. 

    4. You can check the profileArray in the function wlan_smart_config_process, after the decryption to check if the correct AP details are received at CC3000 side.

    Thanks & Regards,
    Raghavendra

  • 0 in reply to Raghavendra Shenoy
    Intellectual 310 points

    Raghavendra Shenoy Mathav said:

    Moving to latest host driver means replacing the existing CC3000HostDriver folder with the one that comes with the latest host driver release package. In your case, the host driver folder CC3000HostDriver in the latest patch programmer source will contain the latest host driver.

    You reference the CC3000HostDriver folder but there are multiple folders with that name in the release package. I'm going to assume you mean the one that contains the actual source code?

    This statement from the release notes:

    The release package 1.13 will contain only the Service Pack update. This Service Pack should be used with the Host Driver that is part of the release package 1.12.

     doesn't make sense to me because when I installed release package 1.13, I got a Host Driver source directory (C:\ti\PatchProgrammerMSP430FR5739-1.13.7.15.28\Patch Programmer Source\Source\CC3000HostDriver\) which contains the exact same source code as in release 1.12. Can someone explain which files constitute the "Service Pack update" vs those that constitute the "release package"? Is that release note just wrong? 

    Based on the above, I'm going to assume that I did use the correct Host Driver when I installed the 1.12 and 1.13 release packages.

    I'm now thinking that when I want to build the Sensor Application or Basic WiFi Application, that I first need to copy over the source files in the CC3000HostDriver folder to the appropriate place in the application tree (e.g. for Sensor Application this would be C:\ti\CC3000FRAMSensorApp\CC3000_FRAM_Applications\Source\CCHostDriver)? Is that correct? It appears that the CCHostDriver that came with the Sensor Application (back in release 1.10.2) is still functional because I did get that working (using the TP-Link router) after I had run the patch programmer for both 1.12 and 1.13...

    Since my only purpose in using the Sensor Application was to verify basic connectivity and data transfer functionality, I don't really have a need to run it anymore and will transition to using the Basic WiFi Application as that appears to be more up-to-date. I compared the CCHostDriver source folders in each and found:

    • CCHostDriver source in Basic Wifi Application (CC3000SDK release 1.12) is up-to-date (same as Patch Programmer release 1.13)
    • CCHostDriver source in Sensor Application is not up-to-date (different from Patch Programmer release 1.13)

    I suspect that the out-of-date Host Driver in the Sensor Application may be the source of my problem.

    My new problem is that now I can no longer communicate (using putty) with the board with the Basic WiFi Application loaded. I tried both loading the application using the binary shortcut and by building it in CCS5.5 and loading it through the debugger. In each case, putty is unable to open a serial connection to the board (yes, I did configure the port appropriately in Device Manager and use the same port settings in putty). In case it is relevant - LED5 is lit when the Basic WiFi app is running.

    Raghavendra Shenoy Mathav said:

    1. If you are using the encryption key, make sure that 'CC3000_UNENCRYPTED_SMART_CONFIG' is not defined.

    I am NOT using encryption so I'm assuming that CC3000_UNENCRYPTED_SMART_CONFIG should be defined. I searched all the source code in the Basic Wifi Application and it's not defined (or undefined) anywhere. Do I need to add that to one of the source files or add it as a compiler flag in the project?

    Thanks,

    Craig

  • 0 in reply to Craig Heilman
    Expert 1140 points

    Hi Craig,
    the CC3000HostDriver is exactly the same between versions V1.12 and V1.13 - there was no change. In V1.13 only the firmware was changed (the part that gets saved in CC3000 EEPROM). Thus for CC3000 with firmware V1.13 you just keep using the 1.12 SDK, incl. also the BasicWiFiApplication example.

    Cheers,
    Risto

  • 0 in reply to Risto Koiva
    TI__Mastermind 27095 points

    Hi Craig,

    The steps that you have followed are correct. The Sensor Application will use the older drivers by default. Going with the Basic Wifi Application available with the release 1.12 is the right way to go about it.

    If you are not using encryption, then CC3000_UNENCRYPTED_SMART_CONFIG should be defined. It should be defined in the project property. And you should also make sure that you call wlan_smart_config_start with an argument '0'.

    Thanks & Regards,
    Raghavendra