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.

Trouble using wlan_ioctl_get_scan_results

Other Parts Discussed in Thread: LM3S300, MSP430FR5739, MSP430F5438, CC3300

I am having trouble using the wlan_ioctl_get_scan_results function.  I think there might be a problem with the structure type (WLAN_San_Result_t) that is passed into the function not matching what is actually returned byt the cc3000.

The defintition of the function in the Simplelink API reference manual does not match up with the actual definition in wlan.c

 

-------------------------------- Here is the documentaion for the function call ------------------------------------

 

long wlan_ioctl_get_scan_results ( unsigned long  ulScanTimeout,
unsigned char *  ucResults 
)

Gets the WLAN scan operation results.

Gets entry from scan result table. The scan results are returned one by one, and each entry represents a single AP found in the area. The following is a format of hte scan result:

  • 4 Bytes: number of networks found
  • 4 Bytes: The status of the scan: 0 - agged results, 1 - results valid, 2 - no results
  • 44 bytes: Result entry, where the bytes are arranged as follows:
  • 4 bytes isValid - is result valid or not
  • 4 bytes rssi - RSSI value;
  • 4 bytes: securityMode - security mode of the AP: 0 - Open, 1 - WEP, 2 WPA, 3 WPA2
  • 4 bytes: SSID name length
  • 2 bytes: the time at which the entry has entered into scans result table
  • 32 bytes: SSID name
  • 6 bytes: BSSID

------------------------------- Here is the structure defined in wlan.c -------------------------------------------

 

#ifdef __CCS__
typedef struct __attribute__ ((__packed__)) _WLAN_San_Result_t
#elif __IAR_SYSTEMS_ICC__
#pragma pack(1)
typedef struct _WLAN_San_Result_t
#endif
{
    //
    // Set to 1 if this entry is occuiped
    //
    unsigned long isValid    : 1;
    long rssi       : 7; 

    //
    // Holds one of the parsed security-modes
    // SECURITY_OPEN, SECURITY_WEP, SECURITY_WPA, SECURITY_WPA2,
    //
    unsigned long securityMode : 2;
    long ulSsidLen     : 6;

    //
    // The time of which the frame has enterd (in seconds)
    //
    short         frameTime;

    //
    // AP name and MAC address
    //
    char          ssid[MAXIMAL_SSID_LENGTH];
    unsigned char ucBssid[ETH_ALEN]; 

}WLAN_San_Result_t;

 

Problems

1) It says 44 bytes follow but the bytes listed add up to 56

2) The structure does not match documentation.

 

I found that if this is called multiple times, the driver evenually crashes.  I was able to change the structure and get it to work using this as my structure:

typedef struct wlan_test_get_scan
{
    unsigned long num_networks;
    unsigned long scan_status;
    unsigned char byte1;
    unsigned char byte2;
    unsigned short time;
    unsigned char ssid_name[32];
    unsigned char bssid[6];
}wlan_test_get_scan;

As you can see this also does not match the documentation.  I came up with this after tracking the problem to where the data is copied in the hci_event_handler.

 

So, can you please confirm the data format for the wlan_ioctl_get_scan_results and the bit packing for the results?

 

Finally, is there additional documentation that gives the api for the cc3000 part (not the driver, but the chip itself)?

 

Thanks

 

 

 

 

  • Jeffrey,

    We'll look at this and come back to you.

    Regards,
    Gustavo

  • Hello Jeffrey,


    I am facing the same problem right now. My colleague, who evaluated CC3000, told me, that the function documentation from the header is invalid. He partially decrypted the format but unfortunately he can provide it to me tomorrow at the earliest. He also told me, that struct from wlan.c is also incorrect. I assume that you are almost there, but I will appreciate if Gustavo provide us proper documentation.

    Martin

  • Hello 

    Can you please let us know based on which CC3000 Host Driver source code you are working?

    Which application you are based on?

    Regards,

    Igor

  • The version that prints out the serial port is 1.6.2.2.  I have ported the Basic Wifi Application to a non-DMA Stellaris micro (LM3S300).  I have downloaded every demo version available on the wiki and they all use the same driver code (as far as I can tell).

    I do want to ask again if there is a API document available for  the CC3000 hardware part (not the driver code API)?

    Jeff

  • Hello Jeffrey

    We are currently using host version 1.7.2.2 so I would suggest using it.

    More than that what are I would suggest you to check is that the CC3000 Host SPI buffer is at least of size 150 bytes for RX and150 for TX.

    On top of that what type of HW documentation you are looking for? We have a modules DS, from LSR and from Murata.

    Is that what you are looking for?

    Regards,

    Igor

  • I don't think the host version or the spi buffers is at the core of the problem.  Have you had a chance to look into the structure definition that I noted in the original post?

    The type of documentation I am looking for is the type that would be needed if I was writing the CC3000 Host Driver.  If I had a document that gave the API for the CC3000, I could have checked what data was coming out of the module when I issued the get scan results command and checked it against the structure definition.  Does that make sense?

    Jeff

  • Hey Jeff,

    There is no proper documentation that allows user to re-write the host driver, sorry about that.

    So my suggestion is to use the latest CC3000 Host Driver available on the WiKi together with the latest documentation (Doxygen 1.7.2.2)

    More than that from looking into code the wlan results are returned in the format of:

    {
    //
    // Set to 1 if this entry is occuiped
    //
    unsigned long isValid : 1;
    long rssi : 7;

    //
    // Holds one of the parsed security-modes
    // SECURITY_OPEN, SECURITY_WEP, SECURITY_WPA, SECURITY_WPA2,
    //
    unsigned long securityMode : 2;
    long ulSsidLen : 6;

    //
    // The time of which the frame has enterd (in seconds)
    //
    short frameTime;

    //
    // AP name and MAC address
    //
    char ssid[MAXIMAL_SSID_LENGTH];
    unsigned char ucBssid[ETH_ALEN];
    }WLAN_San_Result_t;

    Is this what you are observing?

    Regards,

    Igor

  • Igor,

    This is not what I am observing.  Can you please look at my original post again, it explains what the documentation states, how the driver code is currently implemented, and what I needed to do to get this to work.

    Jeff

  • Hello Jeffrey,

    Please align your code (and documentation) of theBasic WiFi Application to the latest one.

    There definitely is a correct description of the strucuture.

    The link to updated Doxygen is:

    http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_for_MCU#CC3000_Doxygen_APIs

    More than that can you please share with me a code sample that causes a crash on CC3000 Host Driver?

    Regards,

    Igor

  • When you say there is a correct description of the structure, can you list here what it is?  My confusion is this:

     

    1) The Doxygen documents states (52 bytes I think, the breakdown of the 44 bytes does not add up to 44)

    long wlan_ioctl_get_scan_results   (unsigned long ulScanTimeout,  unsigned char * ucResults )
            

    Gets the WLAN scan operation results.

    Gets entry from scan result table. The scan results are returned one
    by one, and each entry represents a single AP found in the area. The
    following is a format of hte scan result:

    • 4 Bytes: number of networks found
    • 4 Bytes: The status of the scan: 0 - agged results, 1 - results valid, 2 - no results
    • 44 bytes: Result entry, where the bytes are arranged as follows:
      • 4 bytes isValid - is result valid or not
      • 4 bytes rssi - RSSI value;
      • 4 bytes: securityMode - security mode of the AP: 0 - Open, 1 - WEP, 2 WPA, 3 WPA2
      • 4 bytes: SSID name length
      • 2 bytes: the time at which the entry has entered into scans result table
      • 32 bytes: SSID name
      • 6 bytes: BSSID
    Parameters:
       
    [in] scan_timeout
       
    [out] ucResults scan resault (WLAN_San_Result_t)
    Returns:
    On success, zero is returned. On error, -1 is returned
    See also:
    wlan_ioctl_set_scan_params
    Note:
    scan_timeout, is not supported on this version.

    2) The structure definition in wlan.c is (56 bytes)

    #ifdef __CCS__
    typedef struct __attribute__ ((__packed__)) _WLAN_San_Result_t
    #elif __IAR_SYSTEMS_ICC__
    #pragma pack(1)
    typedef struct _WLAN_San_Result_t
    #endif
    {
     //
     // Set to 1 if this entry is occuiped
     //
     unsigned long isValid    : 1;
     long rssi       : 7; 

     //
     // Holds one of the parsed security-modes
     // SECURITY_OPEN, SECURITY_WEP, SECURITY_WPA, SECURITY_WPA2,
     //
     unsigned long securityMode : 2;
     long ulSsidLen     : 6;

     //
     // The time of which the frame has enterd (in seconds)
     //
     short         frameTime;

     //
     // AP name and MAC address
     //
     char          ssid[MAXIMAL_SSID_LENGTH];
     unsigned char ucBssid[ETH_ALEN]; 
    }WLAN_San_Result_t;

     

    3) I found that when debugging the code that the structure definition needed to be this (50 bytes):


    typedef struct wlan_test_get_scan
    {
        unsigned long num_networks;
        unsigned long scan_status;
        unsigned char byte1;
        unsigned char byte2;
        unsigned short time;
        unsigned char ssid_name[32];
        unsigned char bssid[6];
    }wlan_test_get_scan;

     

  • Hello Jeffrey ,

    I finally understand your issue and I am sorry very much for such a long responce time.

    You observation is correct and requires a fix of documentation in the upcomoming version.

    The structure of the scan result is as follows:

    long Count 

    long ScanResultState

    //
     // Set to 1 if this entry is occuiped
     //
     unsigned long isValid    : 1;
     long rssi       : 7; 

     //
     // Holds one of the parsed security-modes
     // SECURITY_OPEN, SECURITY_WEP, SECURITY_WPA, SECURITY_WPA2,
     //
     unsigned long securityMode : 2;
     long ulSsidLen     : 6;

     //
     // The time of which the frame has enterd (in seconds)
     //
     short         frameTime;

     //
     // AP name and MAC address
     //
     char          ssid[MAXIMAL_SSID_LENGTH];
     unsigned char ucBssid[ETH_ALEN]; 

    We will update the documentation and the code itself.

    Regards,

    Igor

  • Hello,

    this definition seems to fit the data I observe and the structure my colleague assembled. It is probably not completely right, because RSSI is acting a little bit weird (one network -45(dBm?), second 60), but rest of it looks fine.

    {
    unsigned long networksFound;
    unsigned long scanStatus;
    unsigned long isValid : 1;
    signed long rssi : 7;
    unsigned long securityMode : 2;
    unsigned long ulSsidLen : 6;
    unsigned long frameTime : 16;
    char ssid[32];
    unsigned char ucBssid[6];

    } wifi_scan_result_t;

    Basically scanning seems to depends on other conditions. I am unable to scan (start scan by setting scan parameters and calling get scan result) any network until I try to associate CC3000 to any network (no matter if it is in the area/if I'm successful with association or not).

    If I try to associate I can get data from get scan result function even when I haven't enabled scanning by set scan parameters command, but basically I can get only two networks from get scan result although there are something like 6 networks in the area (powerful enough that It should be scanable).

  • Hello Martin.

    Please note that in general scanning is enabled in CC3000 by default, so you do not have to enable it. You may disable it though.

    Can you please share the code sample performing a get scan results task?

    Regards,

    Igor

  • Hello Igor,

    I am using modified SensorApplication demo, but I got rid of server and waiting for association from state machine in the main(). I enhanced command line to be able to control CC3000, so I implemented several more commands to be able to connect to secure network, set IP address manually/by DHCP, disconnect, scan, etc. I followed programmers guide on your Wiki so my scan command is implemented by following code (added to terminal.c in SensorApp demo runUARTterminal() ).

    When I run "scan" command after reset, I get nothing. When I start scan by "scan start" (wlan_ioctl_set_scan_params(1,....)) and than use "scan" (wlan_ioctl_get_scan_results()) I get nothing again. Only way how to gather data from wlan_ioctl_get_scan_results() is by typing "assoc xxx" (wlan_connect() no matter what ssid, only attempt is enough), then I get some results, no matter if I type "scan star/stop". Second strange thing is, that I am unable to get more than two results from get scan results command and my colleague has the same experience (in both cases there has been more than just two strong networks in area).

    runUARTterminal()
    {
    ............
         else if(checkCommand(uartRXBytePointer(validPos),"scan") == 1)
    {
    if(argn == 2)
    {
    validPos += strlen("scan");
    while(uartRXByte(validPos) < '.' && validPos <= bytesInUart() )
    validPos++;
    if(checkCommand(uartRXBytePointer(validPos),"stop") == 1)
    {
    wifi_scan_mode(0);
    sendString("Scan disabled");
    }
    else if(checkCommand(uartRXBytePointer(validPos),"start") == 1)
    {
    wifi_scan_mode(1);
    sendString("Scan enabled");
    }
    else
    {
    sendString("Invalid argument - use start/stop");
    }
    }
    else if(argn == 1)
    {
    char ssid[64];
    int ssidLen;
    int sec;
    int rssi;

    int attempt = 0;
    int upperLimit = wifi_scan_result(&ssid[0], &ssidLen, &sec, &rssi);
    if(upperLimit == -1)
    {
    sendString("No network in the arrea");
    }
    else
    {
    while(attempt < upperLimit)
    {
    printScanResult(&ssid[0], &ssidLen, &sec, &rssi);
    wifi_scan_result(&ssid[0], &ssidLen, &sec, &rssi);
    attempt++;
    }
    }
    }
    .............
    }
    
    
    int wifi_scan_mode(int enable)
    {
    static unsigned long channel_interval_list[16] =
    {
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST,
    WIFI_SCAN_CHANNEL_INTERVAL_LIST
    };

    return wlan_ioctl_set_scan_params(
    enable, 20, 30, 2, 0x1FFF, -80, 0, 205, channel_interval_list
    );
    }

    int wifi_scan_result(char *ssid, int *ssidLen, int *security, int *rssi)
    {
    static unsigned char buffer[50];

    wifi_scan_result_t *result = (wifi_scan_result_t *) buffer;

    memset(buffer, 0, sizeof(buffer));

    if (wlan_ioctl_get_scan_results(WIFI_SCAN_CHANNEL_INTERVAL_LIST+10000, buffer) != 0)
    {
    return -1;
    }

    if (result->isValid != 1)
    {
    return -1;
    }

    memcpy(ssid, result->ssid, result->ulSsidLen);
    ssid[result->ulSsidLen] = '\0';
    *ssidLen = result->ulSsidLen;
    *security = result->securityMode;
    *rssi = result->rssi;

    return result->networks_found;
    }
  • Martin-

    I am having a similar problem as you and your colleague are having. I am not able to "scan" all the available APs in the area. Initially I wasn't able to scan any APs then I did a "first time configuration" and noticed after that I was able to scan/detect that AP when  issuing a wlan_ioctl_get_scan_results. I then added a second/different AP using the "first time configuration" and low-and-behold after issuing a wlan_ioctl_get_scan_results after that the original as well as the second AP showed up in my results. It appears as tho the only AP the wlan_ioctl_get_scan_results returns are the available APs that are stored in the CC3000s.

    FYI- I did turn off one of the APs and reran the scan and it didn't return that AP in the result. I was just making sure the wlan_ioctl_get_scan_results function wasn't returning the stored values.

    I hope this get fixed soon as it would be nice to be able to scan and choose what AP to connect to depending on where you are.

    Jason

  • Hello Jason,

    thank you for confirmation. I agree that there is "something rotten" in CC3000 around scanning functionality. I hope it will be fixed soon too.

  • Hello Martin

    CC3000 has its scans enabled by default.

    Please note that when you are connected the scans are performed each 10 minutes (refreshed each 10 minutes).

    On top of that can you please clarify me how do you know that you are not able to scna while you are not connected?

    Regards

    Igor

  • Hello Igor,

    as I described before I don't get any valid data from wlan_ioctl_get_scan_results() until I attempt to connect to any witeless network. So no matter if I enable scannig by wlan_ioctl_set_scan_params ( 1, ....) or not, wlan_ioctl_get_scan_results() returns zero (command successfull) and return scan result sruct is filled by zeros except status of the scan which is 2 = no results.

    I must call ConnectUsingSSID() from CC3000.c to be able to scan anything. Then if the SSID of network is not in the area, I can scan only one (strongest) network in the area (number of scanned networks hadn't exceeded no. 1).

    When I call DisconnectAll() from CC3000.c (or wlan_disconnect(); from wlan.h, I am not sure if DisconnectAll() was implemented out of the box), or when I call assoc and successfully connect to a network, I can scan for networks too, but still I cannot get any better result then only two networks in the area. And it is definitely not because of weak signal of other networks, because there are about 7 networks in the area and it depends on fortune which one I scan as a send result (first one is always the TP-Link AP on my table).

    That is my observation.

    edit:

    Sometimes I get three networks, but the first char in SSID field of result structure is zero, so it is not printed correctly (SSID is 0x00, r, b, a, 0x00 instead of V, r, b, a, 0x00);

  • Hi

    I will attempt to re-create the problem and will explain you the behavior.

    Regards

    Igor

  • Igor,

    I have seen the same behavior where the scan will not return any results unless a wlan_connect() has been previously attempted.  There is also some time delay between when wlan_connect() is called and when the scan results are valid.

    Is there ANY documentation or design notes that actually explain how the module is working internally?  I'm finding myself having to 'try things out' with respect to timing and function sequence with this module, similar to what others have been describing on the forum.  Another issue I've found is that I have to put a delay between wlan_disconnect() and a subsequent wlan_connect() for the new connect command to 'take hold' in the module.  Even when the wlan_connect() function returns 0, it is clear that the module has not started connecting yet (indicated by wlan_ioctl_statusget() returning 0 instead of 2).  And I can even get the module into a state where wlan_ioctl_statusget() continually returns 2 without ever successfully connecting to an AP, even though I've been able to successfully connect to that particular AP previously.

    Thanks,

    Andy

  • Hi Andy,

    There is no documentation available on the internal logic of the scan.
    We are working to recreate the problem and fix it.
    I'll update you on our progress in the next couple of days.

    Thanks,
    Alon.S 

  • Hello Alon,

    Have you checked this problem? Because I experienced the same behaviour 

    with scanning and missing the SSIDs so I would be grateful if you can help me with that. Do you have errata of the 

    HW/SW?

    /Roman

  • Hi Roman,

    We are currently working on a fix for the scan issue you reported on this topic but we don’t have a timeline for this release yet.

    Yael

  • Hi Yael,

    Thank you for the answer. I'm looking for the new release. Can I ask you for the errata, debug list

    for the SimpleLink API?

    /Roman

  • Hi Roman,

    Please find the known issues list in the release note:

    http://processors.wiki.ti.com/index.php/CC3000_Release_Note

    Yael

     

  • Hello  All,

                  I am also facing some issues related to Scan AP  function. Initially i was able to Connect to AP,  IP configuring(Both DHCP/ Static), Open Sockets(Both TCP/UDP), Send/Receive data Successfully. All these functionality i tried with CODE, not UART operation.

                 Then i tried for SCAN function, after that it was not at all connecting to access point. Not receiving any CC3000 connected flag in handler. I am unable to proceed with the things. Can you please guide if you have faced a similar issue.

     

    I am using CC3000 Wi-Fi kit, interfaced  with MSP430FR5739 development board

     

                Doubts: When we set the scan parameters, where does these settings save to. ???

                             Is this problem due to invalid setting of parametes ???  

     

    Regards Amit G.

     

  •  Hi Amit,

    The scan parameters are saved to the EEPROM.

    Can you please specify the exact API you apply? Which scan parameters did you configured?

    Yael

  • Hello,,

              Initially i used API wlan_ioctl_set_scan_params(1, NULL, NULL, NULL, NULL, NULL,NULL, NULL). Then later i found that there are some defaullt settings to be entered, i altered the API   wlan_ioctl_set_scan_params(1, 20, 30, 2, 0x7FF, 80,0, 205, NULL);

    What is that last parameter, it should be an array of scanning timeouts???

    Can u just insist me to scan the available networks??

    with Regards,

    Amit G

  • Amit,

    The last parameter is array of scan intervals.

    The first parameters actually enable and disable the scan.

    There is a known issue with wlan_ioctl_set_scan_params that will be fixed in the upcoming release but it should effect cc3000 connection to an AP.

    After applying wlan_ioctl_set_scan_params(1, 20, 30, 2, 0x7FF, 80,0, 205, NULL) , were you able to get the scan results? you can do that by using this API:

    wlan_ioctl_get_scan_results()

    Were you able to connect to AP?

     

    Yael

  • Hello Yael,

                  Yes you are right... Its not connecting to AP.

                  Code will be waiting for the ulcc3000connected flag, This perticular flag is not setting. (AP not connected).

                  We tried to debug it, it didnt solve.

                  No it was not possible to get the scan results.  

     

     Amit G.

                 

     

                

     

  • Hi Amit,

    Are you using First time Config in order to connect to the AP?

    Or are you using wlan_connect?

    Please describe your steps.

    If you are using a static IP please be aware that you shouldn't wait for ulCC3000DHCP event (remove it from the code).

    Yael

     

  •  

    Hello Yeal,

                   I have a question :  Are those sacn related issues related to software (device driver) or hardware (IC, so TI need to fix it on their next release)?

     

    Amit

  • Hi Amit,

    This issue is related to software and will be fix in the upcoming release,

    Yael

  • Hi Yael.

               Okey...

               So its the problem with CC3000 Device Driver ?

               One more Doubt Yael : The netapp_ipConfig() API is not reporting Valid IP Parameters.. Does this issue has been faced before by any customer ??

               I had seen in TI release Note that, this API has some Issues.. Is this issue resolved.????.

     

    Amit G 

              

                 

            

  •  Hi,

    The scan issue was a problem is in the CC3000 controller code and the fix will be provided by a patch in the upcoming release.

    Regrading the NetappIPconfig ()  known issue, from the TI release note:

    "If the device is configured to use static IP, and connected to the AP, and the IP address is re-configured, the API command NetappIPconfig will return incorrect IP address".

    Meaning, only if you configure static IP when you are connected to an AP, and then reconfigure your static IP, the IP return from NetappIPconfig will be incorrect.

    Since you have the IP parameters (you configured it to be static...) this issue is not a barrier.

    This is the only known issue with NetappIPconfig ,

    Yael

  • Hi Yael,

                Today i had a meeting with our Management, We have decided to use CC3000 Wi-Fi Module in 3 of our projects, which has Wi-Fi applications. We want to know whether the issues listed in the http://processors.wiki.ti.com/index.php/CC3000_Release_Note link are only related to CODE or HARDWARE. Please confirm it once again so that we can proceed with our Hardware related design.  We have to take decisions at the earliest.

                 If its a CODE (Driver Issues) when is TI relaesing the Resolved Version.

     

    With Regards,

    Amit G 

     

     

  • Hi Yael,

             NetappIPconfig ()  issue,

             This issue has also occured in DHCP Mode,

             Its not getting the IP Parameters for the above API. It is continuing with the further API's like Socket open, Connect, Send, Receive Successfully.

     Amit G

          

  • Amit,

    There is no known issue with NetappIPconfig() and DHCP.

    Can you please specify the API you apply? What are the NetappIPconfig () params?

    Can you tell what IP did you received from the AP (look at the AP GUI configuration under connected devices).

    Can you ping cc3000 with this IP address?

    If you wish, in the sensor application there is a reference for using NetappIPconfig. After connection is establish, IP is taking from NetappIPconfig and printed to the hyper terminal.

    The sensor application can be download from here:

    http://www.ti.com/lit/zip/swrc234

    Sensor app wiki page:

    http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_MSP430_FRAM_Getting_Started_Guide

    Yael

     

  •  

    Hi Yael,

                Today i had a meeting with our Management, We have decided to use CC3000 Wi-Fi Module in 3 of our projects, which has Wi-Fi applications. We want to know whether the issues listed in the http://processors.wiki.ti.com/index.php/CC3000_Release_Note link are only related to CODE or HARDWARE. Please confirm it once again so that we can proceed with our Hardware related design.  We have to take decisions at the earliest.

                 If its a CODE (Driver Issues) when is TI relaesing the Resolved Version. Revert Back

    With Regards,

    Amit G

  • Hi Amit,

    The issues are all internal CC3000 SW issues.
    However, CC3000 is a ROM device, meaning it is possible to fix issues but it's not trivial due to different aspects.
    We are always working on bug fixes and new features and some of the issues in the list will be fixed in the upcoming release.

    However, Not all of the issues will be fixed.
    Do you have any specific issues that you have higher priority for?

    Thanks,
    Alon.S

  • Hello Alon,

                     Presently we have Scanning of Access Points as  high Priority issue, since all the applications are mainly based on the scanning.

                     CC3000 scans only 2 access points.

                    So will this issue be solved in the upcomming release.  

     

    Amit

  • Hi Amit,

    We have a fix for the scan issue in our upcoming release,

    Yael

  • Was this solved in 1.7 that was released? Or is that an old release? Any news on this?

  • Hi Melik,

    The new host driver (v10) and patches (v1.7)  release contains two fixes:

    1. Correct description of the return scan param.
    2. Previously when you want to issue a scan with wlan_ioctl_set_scan_params() the scan would be issued only after 10 min. Also, the default interval between the scans was 10 min and wasn’t configurable.The fix was to issue one shout scan whenever you call  wlan_ioctl_set_scan_params() and let the user the option to configure the scan interval (minimum one second).

    This fix did improve the stability of the scan results, therefore I suggest to give it a try.

    In order to see all the fixes and added features in the new release please review C3000 Release Note:

    http://processors.wiki.ti.com/index.php/CC3000_Release_Note

    Yael

  • Hi Yael,

    Thanks for the new information! Unfortunately, both the links for the Patch Programmer and the MSP430 Host Driver seem to be down, and they've been down since I first found them.

    Also, do you know if both of these updates are compatible with an MSP430 device other than the MSP430FRAM? All these examples seem to give that as the device they use. I have the MSP430F5438, and the Basic WiFi application was ported to it. Can I just update the Host Driver project in the workspace without affecting the functionality of the ported CC3000 software? The Basic WiFi app for my board hasn't been updated in a long time, that's why.

    Thanks,

    Melik

  •  

    Hi Melik,

    The links for the patch programmer are active since two days ago:

    http://processors.wiki.ti.com/index.php/CC3000_Patch_Programmer#Download_the_Patch_Programmer_installer

    The link for MSP430 host driver has always been active and was updated for the new version two days ago:

    http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_Downloads#CC3000.2BMSP430_FRAM_Downloads

    The version update is not available for MSP430F5438 yet. It will be in the near future.

    You can either wait for our release or you can port the application yourself basing on the new MSP430FRAM code.

    Basically you just need to update the host driver but be aware that in the basic WiFi Application we moved all related board functions to a separate file named board.c.

    Other than that, everything should be pretty trivial.

    Yael

  • Hello Yael,

    I lack the expertise to port the host driver to the MSP430F5438 myself, so I'll be looking out for the update for that! I'm assuming the Patch Programmer has to be ported to the MSP430F5438 as well, since I ran the version from the link you provided but no LEDs turned on like it said it would.

    Hopefully these ports are made soon, since the scanning corruption is a big problem for the application for which I'm using the CC3000.

    Thanks,

    Melik

  •  

    Hi Melik,

    The host driver is platform independent, therefore there is no need to port it, just apply the changes that we made for the new version.

    Or, you can wait for the Basic Wifi Application for MSP430F5438 formal release.

    The patch programmer release is for MSP430FR5739. This release won't work on MSP430F5438 .

    But, the porting should be quite easy. You can use the SPI driver you already have from the Basic Wifi App for MSP430F5438, and in PatchProgrammer.c you just need to change the LEDs GPIOs.

    We also comment the porting needed code, and the non porting needed code.

    There is no future plan to release patch programmer for MSP430F5438.

    Yael

  • hello Yael,

                   Good to hear about the new released patches(1.7).. i have already downloaded the patches using MSP Flasher, and i have verified it using the API nvmem_read_SP_version(), which gave me 17..

                   Now coming to the scan access points, i m facing the same issue. i will tell you my code flow.

            a ) Disable all the previous policy.

            b)  Enable Scan using wlan_set_scan_parameters()

            c)  get_scan_parameters(),

            d) Disable scan.

    I am getting the 2 access points similar to the previous results.

    DOUBT: As per your post, default scan period was 10 mins, so can you please tell me which is that parameter/(API) where we can set scan period for min 1 secs,

    Can you guide me, how to proceed with the relesed patch. i didint find any documents related to scan API for the new released code.

    revert back.,

    Amit.

     

     

     

     

     

        

  •  

    Hi Amit,

    Please note that the comments for wlan_ioctl_set_scan_params() has changed and now supply information on how to set the scan interval parameter.

    In order to set your preferred scan interval please apply it in the first parameter in milliseconds.

    For example, in order to set 1 second scan interval:

    wlan_ioctl_set_scan_params(1000,20,50,5,0x7ff,0xffb0,0,205, intervals);

    Yael