CC3200: cc3200 sl_send() function is blocking

Hi,

No, socket callback is not executed afters values are sent via socket sent API.

Socket API may to be blocking or non blocking. Timeout for socket sent can be set using API SL_SOL_SOCKET  -> SL_SO_RCVTIMEO. If you want to use socket in non blocking mode, you can set socket by API SL_SOL_SOCKET -> SL_SO_NONBLOCKING. For more details see swru368c.

Jan

I wonder why it has been blocked, even if the current connection, the data can always be sent, take a long time will exit. But why does it keep blocking?

Hi,

Socket API calls are by default blocking. But if you are sending relatively big chunk of data (32kB) which does not fit into internal buffers and WiFi connection is slow, sl_Send() API can block for longer time. This is normal.

But nothing prevent you switch socket into non-blocking mode and divide your send data into smaller chunks if you want to have better control at data sent process.

Jan

In fact, I was sending about 1560 bytes every 200ms when this problem occurred. When I used non-blocking communication, sending 1560 bytes in 200ms caused wifi to drop

Hi,

When non-blocking mode is used, you need to monitor return codes. And when error code like a SL_EAGAIN is returned, you need to repeat send attempt.

Jan

I can't find the errno variable, so do I get SL_EAGAIN from the code below, or does sl_send just return SL_EAGAIN

void SimpleLinkSockEventHandler(SlSockEvent_t *pSock)
{
    switch(pSock->Event)
    {
    case SL_SOCKET_TX_FAILED_EVENT:
        switch( pSock->socketAsyncEvent.SockTxFailData.status)
        {
        case SL_ECLOSE:
            logError(TAG,"[SOCK ERROR] - close socket (%d) operation "
                                "failed to transmit all queued packets\n\n",
                                    pSock->socketAsyncEvent.SockTxFailData.sd);
            break;
        case SL_ENOTCONN:
            break;
        case SL_EAGAIN:
            break;
        default:
            logError(TAG,"[SOCK ERROR] - TX FAILED:socket %d , reason (%d)\r\n",
                        pSock->socketAsyncEvent.SockTxFailData.sd,
                        pSock->socketAsyncEvent.SockTxFailData.status);
            break;
        }
        break;
    case SL_SOCKET_ASYNC_EVENT:
        break;
    default:
        logError(TAG,"sock evt.code:%d\r\n",pSock->Event);
        break;
    }
}

/*!
    \brief write data to TCP socket
    
    This function is used to transmit a message to another socket.
    Returns immediately after sending data to device.
    In case of TCP failure an async event SL_SOCKET_TX_FAILED_EVENT is going to
    be received.
    In case of a RAW socket (transceiver mode), extra 4 bytes should be reserved at the end of the 
    frame data buffer for WLAN FCS 
     
    \param[in] sd               socket handle
    \param[in] buf              Points to a buffer containing 
                                the message to be sent
    \param[in] Len              message size in bytes. Range: 1-1460 bytes
    \param[in] flags            Specifies the type of message 
                                transmission. On this version, this parameter is not
                                supported for TCP.
                                For transceiver mode, the SL_RAW_RF_TX_PARAMS macro can be used to determine
                                transmission parameters (channel,rate,tx_power,preamble)
    
    
    \return                     Return the number of bytes transmitted, 
                                or -1 if an error occurred
    
    \sa     sl_SendTo 
    \note                       belongs to \ref send_api
    \warning   
    \par        Example:
    \code       An example of sending data:
    
                SlSockAddrIn_t  Addr;
                _i16 AddrSize = sizeof(SlSockAddrIn_t);
                _i16 SockID;
                _i16 Status;
                _i8 Buf[SEND_BUF_LEN];

                Addr.sin_family = SL_AF_INET;
                Addr.sin_port = sl_Htons(5001);
                Addr.sin_addr.s_addr = sl_Htonl(SL_IPV4_VAL(10,1,1,200));

                SockID = sl_Socket(SL_AF_INET,SL_SOCK_STREAM, 0);
                Status = sl_Connect(SockID, (SlSockAddr_t *)&Addr, AddrSize);
                Status = sl_Send(SockID, Buf, 1460, 0 );
 
    \endcode
 */ 
#if _SL_INCLUDE_FUNC(sl_Send )
_i16 sl_Send(_i16 sd, const void *buf, _i16 Len, _i16 flags);
#endif

This is the comment for sl_send, which states that -1 should be fixed if an exception occurs, not SL_EAGAIN。

This describes returning an error code from a callback function, different from what you said above. Please ask which one should be followed

As Jan said, the event or the status is not returned in the SimpleLinkSockEventHandler, it's following the sl_send API, and it align to the comment.