• State TI Thinks Resolved
  • Locked Locked
  • Replies 18 replies
  • Answers 2 answers
  • Subscribers 40 subscribers
  • Views 385 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.

CC3301: R7 fw stuck issue.

yuan yang
Prodigy 180 points
Part Number: CC3301

Tool/software:

R7 firmware verion is 1.7.5.310, it is unstable and crashes with unknow reason. It crashes during AP scanning and also when connecting to an AP with encryption mode. 

Some workarounds for these issues can make fw didn't carsh:
a. Adding print statements before Wlan_RoleUp(). // fix scan crash issue.
b. Calling Wlan_RoleDown() and Wlan_RoleUp() between scan and connect commands. // fix connecting crash issue.

We need to find the root cuase of fw crash to avoid fw crash in other cases.

  • 0
    TI__Mastermind 31010 points

    Hi Yuan,

    From the FW crash logs we see that the station role up command was not received. Can you confirm that when the wlan_start and wlan_sta_role_up are actually sent to the cc33xx? I would also confirm this by probing the SDIO lines. For some reason the firmware only sees the scan command and without wlan_start and wlan_sta_role_up, the firmware will then crash. 

  • 0 in reply to Sabeeh Khan1
    Prodigy 180 points

    Hi Sabeeh

    I don't know why you can't find wlan_start and role_up commands in fw carsh logs, I upload csv log file for you, you can find these command in it.

    scan_stuck.csv

  • 0 in reply to yuan yang
    TI__Mastermind 31010 points

    Hi Yuan,

    We were able to reproduce this scenario and create the FW crash.

    The crash occurs when NULL is passed into the wlan_roleup command. We noticed from the workaround that you created that you were calling 

    ret = Wlan_RoleUp(WLAN_ROLE_STA, NULL, WLAN_WAIT_FOREVER);

    Which is not correct.

    Please populate the second argument with something like:

    RoleUpStaCmd_t RoleUpStaParams;

    os_memset(&RoleUpStaParams, 0 , sizeof(RoleUpApCmd_t));

    ret = ParseRoleUpStaCmd(arg, &RoleUpStaParams);
    ret = Wlan_RoleUp(WLAN_ROLE_STA, &RoleUpStaParams, WLAN_WAIT_FOREVER);
    The important thing is to populate the countryDomain parameter of the RoleUpStaParams struct.
    You can find example implementation of the ParseRoleUpStaCmd in "examples/network_terminal_common/cmd_parser.c" in the R7 release.
    You can also find the RoleUpStaParams struct defined in "source\ti\drivers\net\wifi\wifi_host_driver\inc_adapt\wlan_if.h". Again, it is crucial to populate the countryDomain[3] parameter as documented in this struct.
    I've copied the snippet from wlan_if.h and pasted it here for your quick viewing:
    typedef struct RoleUpStaCmd
    {
        /* Set regulatory Domain */
        /* The first two characters represent country code: ["00","EU","JP","CS"] */
        /* The third character represent indoor ["I"] */
        /* For example countryDomain = "EUI" (EUrope Indoor) */
        uint8_t countryDomain[3];
        /* Set WPS parameters */
        WpsParams_t wpsParams; //only relevant for CC35xx
        /* P2P enabled/disabled */
        Bool_e p2pDeviceEnabled; //TRUE/FALSE //only relevant for CC35xx
        /* Set P2P Params */
        P2pParams_t P2pParams; //only relevant for CC35xx
    }RoleUpStaCmd_t;
  • 0 in reply to Sabeeh Khan1
    Prodigy 180 points

    Exactly, I've set the RoleUpStaCmd parameter, and the scan works successfully. However, our issue is that when I set a NULL parameter, it also works with the workaround method. Therefore, I think the firewall code needs to be modified to avoid situations where passing a NULL parameter in Wlan_RoleUp()   causes a stuck.
    Additionally, how about the crash case during connection?

  • 0 in reply to yuan yang
    TI__Mastermind 31010 points

    Hi Yuan,

    Yes I completely agree about adding NULL parameter protection. We will add it in the future release. 

    We think the crash in connection would be related. If you use the RoleUpStaCmd parameter, are you still able to create the connection crash?

  • 0 in reply to Sabeeh Khan1
    Prodigy 180 points

    Yes I am still able to create the connection crash even when I use the RoleUpStaCmd parameter.

    The connection crash is mainly related to the scan operation. Below is the test result:

    wifi init -- > wifi scan --> wifi connect failed -> fw stuck  // normal operations
    wifi init -- > wifi scan --> role down sta --> role up sta --> wifi connect success.  // workaround method

    wifi init --> wifi connect success // don't do a scan and connect directly, it will succeed.

  • 0 in reply to yuan yang
    TI__Mastermind 31010 points

    Hi Yuan,

    In the case where you call "wifi init -- > wifi scan --> wifi connect failed -> fw stuck", what security type are you using on the AP? Is it WPA2 or OPEN? Can you try both security types (OPEN and WPA2) and see if the fw stuck occurs on both?

  • 0 in reply to Sabeeh Khan1
    Prodigy 180 points

    Hi Sabeeh

    the security types test result is:

    Open :  has no problem , can be connected success

    WPA2:  has problem , fw will crash.

    WPA3:  has problem, fw will crash.

  • 0 in reply to yuan yang
    TI__Mastermind 31010 points

    Hi Yuan,

    Could you please provide a sniffer capture and FW log of the case of "wifi init -- > wifi scan --> wifi connect failed -> fw stuck" with the WPA2 AP? And which AP model and make are you using?

  • 0 in reply to Sabeeh Khan1
    Prodigy 180 points

    Hi Sabeeh

    I have upload the sniffer file to 
    https://tidrive.ext.ti.com/u/41CR4HrQkfLxUJHu/6e69507b-7d3c-477b-95d7-dcb58a70ab43?l

    you can find connect_stuck.7z on it.

    The AP model I used is Redmi, but I also tested many other routers, and the results are the same.

    Thanks. 

  • 0 in reply to yuan yang
    TI__Mastermind 31010 points

    Thank you Yuan. I see both the FW logs and sniffer capture. Let me work with the dev team and see how we can proceed.

  • 0 in reply to Sabeeh Khan1
    TI__Mastermind 31010 points

    Hi Yuan,

    Our team is still trying to root cause this issue regarding the "wifi init -- > wifi scan --> wifi connect failed -> fw stuck". Can you please try the firmware binaries attached here and collect the FW logs? We have enabled debug prints to help us pin point exactly where the FW is getting stuck. 

    connect_fw_stuck_dbg.zip

    Could you also share your implementation of the wlan_connect and the wlan_scan functions from the C code? We would like to compare as we are still unable to reproduce.

  • 0 in reply to Sabeeh Khan1
    TI__Mastermind 31010 points

    In addition to the above, do you know if you are calling the wlan_set_band function before calling the wlan_scan function?

  • 0 in reply to Sabeeh Khan1
    Prodigy 180 points

    Hi Sabeeh

    I didn't call wlan_set_band function, actually, this Api is not implemented in our driver.

    I have tested your dbg fw, it will carsh during scaning, you can find the fw log fw8_5_scanstuck.pcapng in https://tidrive.ext.ti.com/u/41CR4HrQkfLxUJHu/6e69507b-7d3c-477b-95d7-dcb58a70ab43?l

  • 0 in reply to yuan yang
    TI__Mastermind 31010 points

    Hi Yuan,

    Thank you for collecting these debug logs. We believe we have found the root cause and created a FW fix. Can you please give this a try and let me know if it fixes this connect bug?

    In the case it still fails, I've also attached the logger.bin so that you can collect and provide us the FW logs. 

    connect_fw_fix.zip

  • 0 in reply to Sabeeh Khan1
    Prodigy 180 points

    Hi Sabeeh

    I have tested this fw, the result shows this fw has fixed the connect bug.

    Thanks.

  • 0 in reply to yuan yang
    Prodigy 180 points

    Hi Sabeeh

    This issue is reproduced again when I set country code to "DE" (customer request), the fw carshed during scaning. I have upload fw log (DE_scan_stuck.pcapng) to 

    tidrive.ext.ti.com/.../6e69507b-7d3c-477b-95d7-dcb58a70ab43

     

    please have a check, thanks.

  • 0 in reply to yuan yang
    TI__Mastermind 31010 points

    Hi Yuan,

    As we discussed earlier, the regulatory domain is not the same as the country code. I would recommend to use the reg domain "EU". 

    If you must use a custom domain, it is done by using the wlan_set API. You can read about it in the file source/ti/drivers/net/wifi/wifi_host_driver/inc_adapt/wlan_if.h.