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.

CC3235MODAS: Not getting connect to Wi-Fi router.

Part Number: CC3235MODAS

Hello
We have a very serious issue at our live customer demo site. Please check the exact statement as below.

Problem.

CC3235 is not going to connect with the router.

Test point.

1. Checked for application code it is working.
2. Check Wi-Fi 802.11 log-on sniffer device for this mac_address. It is not transmitting anything.
3. We have put sl_WlanPolicyGet API to test the network processor's health. If the response shows any error for the API then we have rebooted the MCU for testing. But its response is getting proper so the device is not going to reboot. (Not sure it is correct or not.)
4. Connection with Wi-Fi router is in Auto mode. So network processor should connect with the stored Wi-Fi profile automatically.
5. Our device has no option to check the UART log or JTAG.

We need your help to get resolve this problem.

  • Do you have any indication upon receiving async error events from the NWP?

    What happens after you reset the device?

    Does the code contains provisioning? (in the provisioning example, if the device doesn't connect to one of the stored profile within the 2 seconds - it will enter provisioning.

    Assuming you support AP provisioning - you can check if the device is in AP mode.   

    Can you get NWP logs (see chapter 20.1 in https://www.ti.com/lit/swru455).

  • Do you have any indication upon receiving async error events from the NWP?

    --> No, Because devices are not having UART or JTAG interface available.

    What happens after you reset the device?

    --> Reset means restarting MCU. We are doing a Hibernate restart. After that device going to connect with the router.

    Does the code contain provisioning? (in the provisioning example, if the device doesn't connect to one of the stored profiles within the 2 seconds - it will enter provisioning.

    --> Yes we initially, CC3235 in starting phase work as AP mode. After our custom provisioning, we are changing its mode to station mode. And we have checked that if no Wi-Fi profile is available then it is again going to AP mode.

    When the CC3235 is not connected to a router that time we have also checked that the CC3235 is not in AP mode. That is why when we are rebooting the CC3235 will directly trying to connect with the router without provising.

    Can you get NWP logs?

    NO.

    We have a question that if CC3235 is auto connection mode for Wi-Fi router connection mode then why it is stopping sending beacons. If we reboot the MCU then it is working fine. We could not find any perfect scenario till now. Because it is totally random in behavior.

    Our guess is that may router has too many connections so the router rejected that CC3235's request in that case CC3235 goes into some ideal condition.It is not trying to connect anymore. Not sure We are right or wrong. 

    Regards

    Pulkit Prajapati

  • It will be hard to find the root cause without any debug method.

    Can you get an 802.11 air sniffer (e.g. wireshark) capture?

    The device sends beacons only in AP mode, maybe it stopped since it moved to station mode.

    I'm not sure about the behavior when the only profile gets rejected. I guess the auto-connect will keep trying to connect but you should also get an a-sync event in this case (which you can use to reset the NWP (sl_Stop/sl_Start) to make sure it does continue). 

  • Hello  ,

    Thanks for the help.

    Can you get an 802.11 air sniffer (e.g. Wireshark) capture?

    --> Yes, I am sending you in personal message. Please accept my request.

    The device sends beacons only in AP mode, maybe it stopped since it moved to station mode.

    -->Yes, correct but if it is in station mode we have noticed that it is sending a probe request which is captured in air sniffer.

    We have noticed that one device is connected to the router but it is not sending any callback log-like "STA Connected to the AP: xyzw".

    and in that condition, we have "sl_DeviceGet(SL_DEVICE_GENERAL,&configOpt, &configLen,(_u8 *)(&dateTime))" request for time and its response is -2017(SLNETERR_RET_CODE_STOP_IN_PROGRESS).

    so what to do in this condition?

    Summary - two kinds of problems.

    1. One in which device is going to connect but it is stuck inside "MQTTClient_connect(gMqttClient)". and error at "sl_DeviceGet(SL_DEVICE_GENERAL,&configOpt, &configLen,(_u8 *)(&dateTime))" -2017(SLNETERR_RET_CODE_STOP_IN_PROGRESS) in time get request. ( this is the first time captured)

    2. one in which the device is not going to connect with any router and also not sending any packet which is capture in air sniffer. (most of the time this occurs)

    I have few questions about this.

    1. If we capture the NWP log after the device got stuck, then is it helpful to you? because we don't know when which device will have this problem.

    2. what do you mean by the async event? Handler "SimpleLinkSockEventHandler" and its case SL_SOCKET_ASYNC_EVENT. is it right?

    additional points.

    We have already added heap memory and stack overflow hook. But it is not going there.

    Also, we have arranged a UART log for testing devices. But no log comes once the device got stuck.

    Actually, We have an actual 15 devices is live to test this scenario in our lab and almost 30 device is at customer site. So the need for a solution is a very urgent base because it is stuck our production cycle.

    Also, we are trying to capture the NWP log for you. Please wait till again this scenario needs to happen in one of the devices.

    Regards

    Pulkit Prajapati

  • What service pack are you using?

    If possible update to the latest one (4.11.0.0)

  • I approved the connection. Please add the relevant device and router (MAC) address information to the sniffer log.

  • Yes, We are using the latest one.(sp_4.11.0.0_3.7.0.1_3.1.0.26)

  • ok. i'll check the logs and will update when i find anything,