• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 41 subscribers
  • Views 255 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.

CC3235MODSF: Question About TCP Server Flow Using AT Commands

Choongbeom You
Expert 1690 points

Part Number: CC3235MODSF

We are implementing a TCP server using CC3235MODSF (AT command firmware, AP role) and would like to confirm that our socket handling sequence is correct.

Our flow is:

1. socket → bind → listen

2. Wait for +accept: (after issuing at+accept)

3. After connection is established:

   - Use at+select to detect readable data

   - When +select: indicates the socket is ready, send at+recv to read data

4. Continue repeating the select → recv sequence while the connection is alive


We would like to confirm:

- Is this overall sequence correct for a TCP server using AT commands?

- Is it appropriate to continuously repeat select → recv in this manner for data reception?

 

Thanks,

Calvin

  • 0
    TI__Expert 5815 points

    Hi Calvin,

    I'll get back to you on this early next week. I'm assuming you have 2 devices (one of them being CC3235) that are connected to the same network but are trying to talk over a socket?

  • 0 in reply to BLiu
    Expert 1690 points

    The Station device is an Android device, and the other device is being developed as an AP using the CC3235MODSF. The AP is designed to allow only a single Station connection.

    This AP device also includes a LAN module, and we need to develop data transmission and reception between the Station (Android device) and the LAN interface.

    Thanks,

    Calvin

  • 0 in reply to Choongbeom You
    TI__Expert 5815 points

    Hi Calvin,

    Your flow for the most part is correct. You initiate a socket, bind an IP address to it, and listen for a connection. I'm assuming that you accept the connection once the other party initiates a socket connection request. If it is, then yes, your flow is correct.

    It is appropriate to repeat select and recv for your application as well.

  • 0 in reply to BLiu
    Expert 1690 points

    We would like to confirm the following points:

    Question 1

    Is the correct usage to send at+recv whenever we receive +select:<sd>?

    In other words, is +select:<sd> always indicating that data is available to be read from the socket, or can +select:<sd> also be generated for other reasons (for example connection state changes, socket close, etc.)?

    If +select: can be triggered for other reasons besides incoming data, it becomes difficult for us to rely on it strictly as a data-ready indicator.

    Question 2

    When operating a TCP server in AP role, when should the socket be closed and recreated (starting again from at+socket)?

    For example:

    • Should we recreate the socket when the station disconnects from the AP?

    • Or only when the TCP connection itself is closed?

    • Are there specific events that indicate the socket should be closed and recreated?

    We would appreciate clarification on the recommended socket lifecycle management when using the AT command interface.

    Thanks,

    Calvin

  • 0 in reply to Choongbeom You
    TI__Expert 5815 points

    Hi Calvin,

    For question 1, it's not just read, but the only other argument besides read monitoring would be accept monitoring. Please refer to the this page of the user guide.

    For question 2, let me get back to you. If you don't hear from me tomorrow, you should at least get an update from me by Monday.

    Thanks for your patience. 

  • +1 in reply to BLiu
    TI__Expert 5815 points

    Hi Calvin,

    Thanks again for your patience. Let's tackle your three bullets.

    1. Not the listening socket (you may notice that the socket descriptor of the one you're listening on isn't the same as the one used in the connection), but yes on the socket that the station was originally connected on.

    2. This as well.

    3. TX_FAILED, STA_DISCONNECTED, and IP_RELEASED are good ones.