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.

CC3220SF-LAUNCHXL: SL_WLAN_EVENT_DISCONNECT with ReasonCode 110

Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: CC3120, CC3120BOOST

Hello,

I'm having the same issue as in this thread (locked): 

The code 110 doesn't seem to be documented in the SDK.

Sometimes the disconnect happens right after the connection is established and sometimes the connection remains stable for a long time (>30 min).

I'm also observing a strange behavior on the WLAN scan (sl_WlanGetNetworkList):

My AP is the closest one, (o2-WLAN27 in the capture below), but in about 9/10 scans it doesn't appear on the scanned list, even if I get very close (RSSI reporting ~ -25dBm)

The WLAN router is a "Astoria Networks VRV9518SWAC23-B-49", dual band, provided by O2 Germany.

> Number of APs found: 5
> [ 0] SSID[ 9]: o2-WLAN49 , BSSID: 0xe4 0x3e 0xd7 0x4a 0x10 0x85, RSSI: -78, Security: 5256, chan: 7, res: 0
> [ 1] SSID[14]: Garagenhof 2.4 , BSSID: 0x08 0x96 0xd7 0x79 0xc6 0x6d, RSSI: -79, Security: 5828, chan: 6, res: 0
> [ 2] SSID[ 9]: o2-WLAN27 , BSSID: 0xa8 0xd3 0xf7 0xa7 0x3e 0xb7, RSSI: -58, Security: 5256, chan: 6, res: 0
> [ 3] SSID[14]: PYUR Community , BSSID: 0x16 0xb7 0xf8 0xcf 0xb8 0x90, RSSI: -71, Security: 3780, chan: 6, res: 0
> [ 4] SSID[ 9]: o2-WLAN17 , BSSID: 0x04 0xbf 0x6d 0xb3 0x03 0xaa, RSSI: -75, Security: 5256, chan: 13, res: 0

If I try the same board/FW with an Android phone or an RPi3 as AP, the behaviour is very different, the CC3120 connects every time without issues, and the connection range seems very good.

Could you please give me a lead on what could be going on (the reason code will be a good start)? Could be the issue related to dual-band APs?

I'm using the "simplelink_sdk_wifi_plugin_1_60_00_07" SDK

and the Service Pack : "simplelink_sdk_wifi_plugin_1_60_00_07"

My board is a custom design, based on the CC3120 Wide-Voltage Mode Application circuit (CC3120BOOST Schematic)

The layout follows very closely on the critical parts the CC3120BOOST one (SPRCAF9), Vcc=3.3V with <30mV ripple.

I'm attaching pictures of the PCB and the antenna matching measurements (return loss on the RFBG pin31, looks much better than with chip antennas) in case it's useful.

PS: I've also noticed that the voltage on VDD_DIGITAL (pins 9 and 56) seems to jump a bit randomly from 900mV to 1.2V.

Could be that pointing to an issue or the internal LDO is turned on/off during operation?

Thank you in advance!

All the best,

Daniel Mancuso.

  • Hi Daniel,

    Reason code 110 should correspond to "SL_WLAN_DISCONNECT_ROAMING_TRIGGER_BSS_LOSS_DUE_TO_MAX_TX_RETRY". As per Kobi's post here that error code is generally returned when you disconnect from your AP due to missing acknowledgements from the AP when transmitting data.

    Based off of how you describe the AP not even showing up in your scans,and your board connecting without problems to other devices, there could be some interoperability issue. I'll see tomorrow if anyone on the team has experience with that router or similar routers.

    In the meantime, could you collect some NWP logs? You can find instructions here:

    http://processors.wiki.ti.com/index.php/CC3120_%26_CC3220_Capture_NWP_Logs

    Having a log that shows the 110 disconnect error might be helpful.

    Regards,
    Michael

  • Hi Michael,

    Thanks a lot for your quick response!

    I'm attaching logs of the NWP UART output along with the human-readable logs from my application side.

    I've captured the board connecting successfully to my Android phone, transmitting data over TCP (it stays stable without disconnecting, responding to every ping for long periods) and 2 logs connecting to the "Astoria Networks" router and continuous disconnects. I've repeated the test at ~7m and ~40cm from the AP, without noticeable changes in the behavior (except for the expec RSSI).

    I'm also attaching a Wireshark capture during the continuous disconnects in case it helps.

    Thanks in advance.

    All the best,

    Daniel.

    CC3120-NWP&AppLogs.zip

  • Hi Daniel,

    The NWP logs that you provided are unfortunately corrupt. Please double check your settings on the COM port you are using and ensure that they match the settings provided in the wiki page I linked.

    Also, for sniffer captures an air sniffer that records all low level 802.11 packets is required for useful information. The wireshark capture you have provided doesn't really show why a disconnect would occur, since it is from the perspective of the PC running wireshark and only shows the high-level traffic that it received.

    Regards,
    Michael
  • Hi Daniel,

    I assume that you have resolved your issue since I haven't heard back from you. If not, please feel free to post here on this thread or open a new one regarding the issue.

    Regards,
    Michael
  • Hi Michael,

    I still need to make a few more tests with different router brands for confirmation, but it seems that the disconnection issue was actually caused by a small shift on the 40MHz clock:

    During the schematics design and boards assembly we couldn't source the XTALs recommended on the datasheet, so we are using the FL4000157Z from DiodesIncorporated. The XTAL complies with the specifications on the datasheet (ppm, ESR, etc.), but the calibration load capacitance is different than the used in your reference designs, so I needed to tune the oscillator by changing the load capacitors (using this doc which I found very useful).

    It seems that some routers were more forbidding with this carrier frequency shifts than others...

    Thanks a lot for your support!

    All the best,

    Daniel.