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.

LAUNCHCC3220MODASF: SL Wi-FI AT Command Example, No Event For Client Disconnect (with FIN)

Part Number: LAUNCHCC3220MODASF
Other Parts Discussed in Thread: CC3220MODA

I am experimenting with the serial_wifi example which impliments an AT Command control of a serial to Wi-Fi interface.

On a CC3220MODA Launchpad I program the project into the target with JTAG and set up the device as a STA on our network with a socket.  On a desktop computer, I use RealTerminal and send a file with a sequence of AT commands to set up the socket the same way every time.  Our router DHCP server assigns the same IP address each time: 10.1.10.11 which is how I can used a file to hold the commands.

Here is my sequence of commands:

\\<at+close=0
#\\<AT+WlanDisconnect
\\<at+stop=10
\\<at+start
\\<at+socket=inet,stream,tcp
\\<at+bind=0,inet,23,10.1.10.11
\\<at+listen=0,Listen
\\<at+accept=0,inet

To give the CC3220 time to do it's work, I set RealTerminal for about 1 second delay at each new line.

Often, I then confirm that the Launchpad has connected to our network by pinging it from my desktop computer .

I then connect with RealTerminal. I send and received some data from both terminals and then closed the client.

Screen shot after close.

However, when I disconnect the client with RealTerm there is no indication on the CC3220 debug interface of the client disconnection.

Here I have a wireshark capture that shows RealTerminal sent the FIN message which I think closes the socket from the client end.

With out an event, how is the CC3220 server application to know if the client has disconnected?

  • Here is the  interface on the CC3220 UART made after the client socket has disconnected.

  • Forrest,

    If you try to send another message after the socket is closed, do you get a error message returned?

    BR,

    Vince

  • Hello Vince,

    Regarding, "If you try to send another message after the socket is closed, do you get a error message returned?"
    After I close the RealTerminal connection, RealTerminal will not allow me to send another message. It pops up a dialog which says so.

    From the CC3220 terminal windows I sent the "From WiFi" message again and the trafice showed up in Wireshark capture. The serial_wifi application did not alert me that there was no client connection.

    Some screen shots follow. First with RealTerminal set for Raw data.

    And here with RealTerminal set for Telnet.

    Note: The traffic with RealTerminal Telnet mode does not have the Wireshark black colored traffic due to either "Bad TCP" or "Checksum Errors"

    <edit, change tragic to traffic

    P.S.  if I have one supper power it is novel spelling.>

  • Hello Vince,

    Further experimentation and observations.
    I was thinking that when the client closes that a transmit from the server should probably cause the +EventSock Socket Asynchronous Event but never does.

    On page 43 of SWRU534B , table 66 shows that one event is TX_FAILED which I never get.

    Another thing I have noticed. If you look at the screen shot above, after the "+accept=0, inet" line a few lines down is  "TCP Server connection established with 10.1.10.235"  This is an event of some sort coming from the server but it does not follow any pattern in the SWRU534B document which implies events have the form, "+Event....."

    I looked at the AT+Acccept command in table 16 page11 and see no mention of a response like, "TCP Server connection established with 10.1.10.235".  A search of SWRU534B for "TCP Server connection established" returned no hits.

    It seams like the documentation has some errors or am I using incorrect documentation?

  • Notes. Search serial_wifi project and find "TCP Server connection established" on line 830 of serial_wifi.c in the function, SerialWifi_connectProcess.

    There are numerous messages in this function which might appear on the UART under various conditions.

  • Forrest,

    I think currently the AT commands library does not provide feedback when sockets close. I will raise this as a bug internally.

    For you, you might be able to edit the library to add this. I will look into it and get back to you.

    Best,

    Vince