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.

CC3235SF: About sl_ Send() failed to send and returned - 11

Part Number: CC3235SF
Other Parts Discussed in Thread: UNIFLASH, SYSCONFIG,

Hi,

When I use sl_send() to send data to the server, I find that - 11 is often returned. After testing for 60s, 211 times - 11 is returned. What is the reason for this and how to solve it? I found the error code to retry, but I want to know what causes the sending failure? How to solve and optimize it?

Urgent,please help me.

Thanks.

  • Hi,

    This error code (-11) is normal for non blocking sockets. Device is not able to store more data into own buffers. It is likely that you have slow WLAN connection (poor signal) or slow opposite side server. You need to wait moment and repeat your send request. For deeper understanding what is going on you can use network sniffer like Wireshark.

    Jan

  • Hi,

    Because I use the FreeRTOS system and have multiple threads, can I set the socket to block the socket?How to determine whether the network signal is poor? How to use wireShark?

    Thanks.

  • Hi,

    Yes, you can use blocking mode of sockets, if you want - see SWRU455 at chapter 6.7.

    Quality of connection can be determined by reading RSSI (from CC32xx device of from infrastructure access point - e.g. from web interface of AP, iw command via SSH...).

    Description how network sniffer like Wireshark works is out of scope this forum. At internet you find many tutorials. Knowledge of how TCP/IP protocols and knowledge how to use network sniffer is essential for any development with wired or wireless Ethernet devices. Without this knowledge any attempts to working with WiFi not make sense.

    Jan

  • Why can't my program get out of the following code after I set the socket to block the socket? But if I set the socket to a non blocking socket, the program can run. What's the reason?

    Set to block socket

  • Hi,

    Without deeper debugging of your code is hard to say what is going on at your case. It is likely that your issue is not related to blocking socket only. It will be something else inside your code...

    Please wait for hint from other users.

    Jan

  • Hi,

    I am not sure why it doesn't work just from the screen capture but seems related to freertos implementation of the timer.

    In any case, if I concentrate on the original issue, sl_send(), you may get -11 to try again if there are not enough buffers to be used for transmissions or if the other side does not pull the buffers (e.g. slow processor, small TCP window, etc) and the peer's TCP window becomes 0 which signal the simplelink device to stop transmission.

    A wireless sniffer would help here and maybe an NWP log could also help but let's start with the sniffer.

    Regards,

    Shlomi

  • Hi,

    When I debug, I found it stuck in the following place. What is the reason?

    urgent,please.

    Thanks.

  • Hi,

    • What SDK version are you based on?
    • What freeRTOS package are you using?
    • from heap_4 it seems like the heap is directly taken from freeRTOSConfig.h header and specifically from configTOTAL_HEAP_SIZE. What is the value defined in your case?
    • Are you using the example as-is or have you modified it?
    • regards,

    Shlomi

  • Hu wu,

    Do you still use malloc() at ISR context as at this thread?

    Jan

  • Hi,

    I found that after I modified here, the system can run. What was modified here? With cc32xxsf_ freertos.cmd file  of stack _ size and heap_size What's the difference between ?

  • Hi Jan,

    I'm not use malloc() at ISR.

  • Why does malloc fail when I do malloc () in the thread? Its return value is always 0.

  • Why does malloc fail when I do malloc () in the thread? Its return value is always 0.

    malloc in here

    free in here

    urgent,please help me.

    Thanks.

  • Hi,

    My program stops here every time. How should I solve it?

    My malloc () is in one thread, and then free () is free after another thread consumes through the queue. Single programs stay in this place every time. What is the reason?

    It's urgent. Please help solve it in time. Thank you

  • Hi,

    For non blocking sockets, what is the way to reduce the probability of sending failure (i.e. return - 11)?

    Thanks.

  • Hi,

    can you answer on my questions above?

    • What SDK version are you based on?
    • What freeRTOS package are you using?
    • from heap_4 it seems like the heap is directly taken from freeRTOSConfig.h header and specifically from configTOTAL_HEAP_SIZE. What is the value defined in your case?
    • Are you using the example as-is or have you modified it?

    I suggest we concentrate on the -11 return value that indicates there are no buffers internally to serve the sl_Send(). For this, best would be to have an air sniffer log and NWP log.

    Can you capture the air with a sniffer?

    For NWP log, you can read in chapter 20.1 under https://www.ti.com/lit/ug/swru455m/swru455m.pdf?ts=1638204986283&ref_url=https%253A%252F%252Fwww.google.com%252F. To make it short, I suggest is that you add the followings:

    Just above your mainThread(), add:

    #include <ti/devices/cc32xx/driverlib/rom_map.h>

    #define PIN_62 0x0000003D
    #define PIN_MODE_1 0x00000001

    Then inside mainThread() after SPI_Init(), add:

    /* NWP log */
    MAP_PinTypeUART(PIN_62, PIN_MODE_1);

    The rest is described in the user guide's chapter.

    Regards,

    Shlomi

  • Hi,

    I think there is no problem with my network, because I transmit directly through the connection router, and the router has only one port for connection, so what can reduce its return - 11? Such as increasing the sending speed or internal buffer.

    Thanks.

  • Only NWP logger and/or wifi sniffer can give me a good insight.

    Other than that it is just guessing.

  • Hi,

    My 62 pin is used, and we use the board designed by ourselves, not the development board. Then we burn through the burner on the development board. How should I connect here?

    Thanks.

  • 3731.Wireshark.zipHi,

    This is the packet I grabbed with Wireshark. My program got stuck after a while. Can you see what the problem is?

  • Alternative pins for NWP log are:

    MAP_PinTypeUART(PIN_53, PIN_MODE_5);//GPIO30
    MAP_PinTypeUART(PIN_18, PIN_MODE_3);//GPIO28
    MAP_PinTypeUART(PIN_60, PIN_MODE_3);//GPIO5
    MAP_PinTypeUART(PIN_62, PIN_MODE_1);//GPIO7
    Please use one of these lines instead.
    Shlomi
  • This is not an air sniffer but taken on LAN ethernet cable so it is not really usable.

    Do you have an air sniffer option?

    What is our device anyway (IP, MAC address)?

    If not, let's wait for the NWP log.

  • This is a packet captured by Wireshark.

    I don't have air sniffer.

    device IP is 192.168.1.2

    The NWP  log replaceable pins mentioned above are all used. At present, the only remaining pins are GPIO 12.

  • Relevant information of the device, including IP and MAC addresses.

  • Hi wu,

    From provided log from Wireshark it looks there is some kind of communication issue at your TCP socket. But is is hard to say what is going on (whether culprit is your code, your server or your TP-Link AP). Without providing NWP log and log from air sniffer it will be problem to move forward.

    btw1... you did not answered question related to SDK version and ServicePack.

    btw2... maybe you can try to set Always On power policy (see SWRU455 chapter 15.2.1)

    Jan

  • Hi,

    My SDK version is 5_20_00_06.

    The following code is about my socket connection and sending code. Would you please help me see what the problem is?

    int32_t tcp_client_disconnect(void)
    {
        _i16 status=0;
    
        if (!is_connect)
        {
            //UART_PRINT("tcp_connect_close, error, tcp_client_socket < 0");
            return -1;
        }
    
        UART_PRINT("tcp_connect_close, start close\n\r");
    
        is_connect = FALSE;
        /* Calling 'close' with the socket descriptor,
        * once operation is finished. */
        status = sl_Close(tcp_client_socket);
        tcp_client_socket = -1;
        ASSERT_ON_ERROR(status);
    
        GPIO_disableInt(CONFIG_ADS1299_DRDY);//关中断
        UART_PRINT("tcp_connect_close,  close OK\n\r");
        return 0;
    }
    
    int32_t tcp_client_connect( void)
    {
        SlSockAddr_t *sa;
        sockAddr_t sAddr;
        int32_t addrSize;
        int32_t status;
        int32_t nonBlocking;
        ip_t ip_addr;
        int32_t timeout;
    
        ip_addr.ipv4 = wifi_config.server_ip;
        uint16_t portNumber = wifi_config.server_port;
    
        if (is_connect)
        {
            //UART_PRINT("tcp is already connected\n\r");
            return -1;
        }
    
        UART_PRINT("tcp_connect_start, start connect\n\r");
    
        /* filling the TCP server socket address */
        sAddr.in4.sin_family = SL_AF_INET;
    
        /* Since this is the client's side,
        * we must know beforehand the IP address
        * and the port of the server wer'e trying to connect.
        */
        sAddr.in4.sin_port = sl_Htons((unsigned short)portNumber);
        sAddr.in4.sin_addr.s_addr = sl_Htonl((unsigned int)ip_addr.ipv4);
    
        sa = (SlSockAddr_t*)&sAddr.in4;
        addrSize = sizeof(SlSockAddrIn_t);
    
        /* Get socket descriptor - this would be the
        * socket descriptor for the TCP session.
        */
        tcp_client_socket = sl_Socket(sa->sa_family, SL_SOCK_STREAM, TCP_PROTOCOL_FLAGS);
        ASSERT_ON_ERROR(tcp_client_socket);
    
        nonBlocking = FALSE;
        //timeout=30;
        status = sl_SetSockOpt(tcp_client_socket, SL_SOL_SOCKET, SL_SO_NONBLOCKING, &nonBlocking, sizeof(nonBlocking));
    
        if(status < 0)
        {
            UART_PRINT("[line:%d, error:%d], socket = %d\n\r", __LINE__, status, tcp_client_socket);
            usleep(1000000);
            sl_Close(tcp_client_socket);
            tcp_client_socket = -1;
    
            return(-1);
        }
    
         status = -1;
    
        /* Calling 'sl_Connect' followed by server's
        * 'sl_Accept' would start session with
        * the TCP server. */
        while(status < 0)
        {
            status = sl_Connect(tcp_client_socket, sa, addrSize);
            if(status == SL_ERROR_BSD_EALREADY)
            {
                usleep(1000000);
                continue;
            }
            else if(status < 0)
            {
                UART_PRINT("[line:%d, error:%d], socket = %d\n\r", __LINE__, status, tcp_client_socket);
                usleep(100000);
                sl_Close(tcp_client_socket);
                tcp_client_socket = -1;
                return(-1);
            }
        }
    
        is_connect = TRUE;
        UART_PRINT("tcp_connect_start, connect OK,tcp_client_socket = %d\n\r ", tcp_client_socket);
        return 0;
    }
    
    int32_t tcp_client_send(uint8_t* data_buf, uint16_t buf_len)
    {
    
        int32_t status=0;
        uint8_t i=0;
        //UART_PRINT("tcp_client_send, send start\n\r");
    
        if (!is_connect)
        {
            UART_PRINT("tcp is disconnected\n\r");
            return -1;
        }
    
        /* Send packets to the server */
        status = sl_Send(tcp_client_socket, data_buf, buf_len, 0);  //返回的是buf_len
        while(status != buf_len)    //
        {
            count++;
            //usleep(1);
            for(i=0;i<5;i++){
                ;
            }
            status = sl_Send(tcp_client_socket, data_buf, buf_len, 0);
    //        if(status != buf_len){
    //
    //            status = sl_Send(tcp_client_socket, data_buf, buf_len, 0);
    //        }
    //        if(count>=10){
    //            count=0;
    //            break;
    //        }
    //        if(status==-11)
    //        {
    //            count++;
    //        }
        }
        if(status == SL_ERROR_BSD_EAGAIN)
        {
    
        }
        else if(status < 0)
        {
            UART_PRINT("[line:%d, error:%d]\n\r", __LINE__, status);
            usleep(100000);
            tcp_client_disconnect();
            return(-1);
        }
        else
        {
           // UART_PRINT("Tcp client Sent %u packets successfully\n\r", status);
        }
    
        return 0;
    }
    
    int32_t tcp_client_receive(uint8_t* data_buf, uint16_t* receive_len)
    {
        int32_t status;
    
    
        //UART_PRINT("tcp_client_receive, receive start\n\r");
    
        if (!is_connect)
        {
            //UART_PRINT("tcp is disconnected\n\r");
            return -1;
        }
    
        status = sl_Recv(tcp_client_socket, data_buf, MAX_BUF_SIZE, 0);
        if(status == SL_ERROR_BSD_EAGAIN)
        {
        }
        else if(status < 0)
        {
            UART_PRINT("[line:%d, error:%d]\n\r", __LINE__, status);
            usleep(100000);
            tcp_client_disconnect();
            return(-1);
        }
        else if(status == 0)
        {
            UART_PRINT("TCP Server closed the connection\n\r");
            usleep(100000);
            tcp_client_disconnect();
            return(-1);
        }
        else
        {
            //UART_PRINT("Tcp client Receive %u packets successfully\n\r", status);
        }
    
        *receive_len = (uint16_t)status;
        return 0;
    }
    
    bool tcp_is_connected(void)
    {
        return is_connect;
    }
    

  • Hi,

    Do you have uploaded ServicePack from 5.20 SDK into device?

    Jan

  • Hi,

    How to check whether the service pack is downloaded to the device? Because I'm directly in mqtt_ Add my other function modules to the client routine, and sometimes I can run this for a period of time.

    Thanks.

  • Hi,

    Is there a problem with my TCP socket code? Why do I put nonblocking = false; That is, if the socket is set to a blocking socket, the code will not run, but if I set the socket to a non blocking socket, the program can run, but sl_ send() will appear returns - 11. How should I solve it?

    Thanks.

  • Hi,

    The TCP stream looks normal. There are times where the other side is asking to resend some TCP segments but tis is normal congestion in TCP.

    I do not see that the bottleneck is the server but I need a WiFi air capture to see what is going on.

    Please make your best to fetch NWP log as without it the analysis is impossible (even if it means to free one of the pins just for debug).

    As for the servicepack version, you can use the following API. Please send the output.

    SlDeviceVersion_t ver;
            pConfigLen = sizeof(ver);
            pConfigOpt = SL_DEVICE_GENERAL_VERSION;
            sl_DeviceGet(SL_DEVICE_GENERAL,&pConfigOpt,&pConfigLen,(_u8 *)(&ver));
            printf("CHIP %d\nMAC 31.%d.%d.%d.%d\nPHY %d.%d.%d.%d\nNWP %d.%d.%d.%d\nROM %d\nHOST %d.%d.%d.%d\n",
                             ver.ChipId,
                             ver.FwVersion[0],ver.FwVersion[1],
                             ver.FwVersion[2],ver.FwVersion[3],
                             ver.PhyVersion[0],ver.PhyVersion[1],
                             ver.PhyVersion[2],ver.PhyVersion[3],
                             ver.NwpVersion[0],ver.NwpVersion[1],ver.NwpVersion[2],ver.NwpVersion[3],
                             ver.RomVersion,
                             SL_MAJOR_VERSION_NUM,SL_MINOR_VERSION_NUM,SL_VERSION_NUM,SL_SUB_VERSION_NUM);

    Regards,

    Shlomi

  • Hi,

    Yes, I outputeraterm.zipt it.

    I tried to output NWP log. Can you see if it's like this?

  • no, it is not recorded well.

    To be able to check on your side, If the NWP logs are captured successfully from cold boot, you should see some ASCII plaintext in the raw binary logs, most notably the /sys/servicepack.ucf NWP SP file. Furthermore, the 2 bytes of binary data preceding that string will be 0x27 0xCA. If you check for the string + those 2 bytes and see it in your logs, and also see that there are null characters present, then it should be captured correctly and decodable by my tools.

  • Hi,

    1.The 60 pin I use is set like this, right?

    #define PIN_60 0x0000003B
    #define PIN_MODE_5 0x00000101

    MAP_PinTypeUART(PIN_60, PIN_MODE_5);

    2.I use the burner of the development board and connect it to our board. How do I connect the 60 pin I set?

    3.If I use the burner of the development board to burn programs, should I choose COM3 or COM4 as my port? Should the baud rate be consistent with the baud rate set by my code? Or is it set to 921600 as mentioned in the document?

    Please reply as soon as possible.

    Thanks.

  • #define PIN_MODE_5 0x00000101 is incorrect.

    You should use #define PIN_MODE_5 0x00000005

    Always use 921600. It is not related to the uart that is used for application terminal.

    regarding pin60, if you directly solder to the pin, you should be fine. but if you use the launchpad, you cannot just connect to pin60 that appears on the 20-pins header since I think it is not routed there.

  • I don't know how to connect this 60 pin? Is it necessary to connect it to pin 47? Since we didn't lead out the row pins, we just solder the patch, so we may not be able to achieve it. Is there any other way to solve this problem? Can't you judge with Wireshark?

  • Can you help me find and solve the problem as soon as possible? Why is the reply so slow?

  • no, without the logger there is not much i can do. wireshark is not enough. 

    since we are not solely on E2E it takes time to respond.

  • Then it can't be solved? I don't have a pin to get NWP log, that is, I can't solve it and can only give up?

  • Hi,

    You can use any of the alternative pins for NWP log as well. Another option is a remove hardware dependency of your code and test at Launchpad. There is plenty options... this is jut about want to.

    btw ... you did not provide information what Service Pack version do you use.You should use ServicePack 4.11.0.0 from 5.20 SDK.

    Jan

  • At present, only gpio12 is not used on the board. Other pins have been used, and this pin has not been led out. At present, there is no row pin on the board. So how should we operate? Please give me specific solutions and steps.

    Service Pack version

  • Hi wu,

    You need to work with your schematic and hardware. NWP log can be captured from following pins: PIN_62, PIN_53, PIN_18, PIN_60 (pin number from QFN package). You need to check your schematic what is connected to these pins. According type of external components you can determine which can be simple physical removed or disconnected. You need to take into account what is function of this component inside your code. Because you will need to deactivate this component inside your code or create dummy implementation. Important thing is select chip which can be accurately replace by dummy implementation to not affect time behaviour of your code. At hardware side you can:

    • physically remove component (for BGA, QFN packages)
    • lift leg of the chip (this can be easily done for SOP packages)
    • cut a PCB trace, scrape solder mask and solder on it
    • etc...

    It is nice that you show to us your code where you read ServicePack version, but how results of this code look like? What service pack do you use? I think this should be easily obtainable without reading Service Pack version back. Because you need to insert service pack during Uniflash or Sysconfig image creator programming.

    Jan

  • What choice do I have?

  • Hi wu,

    Your service pack looks OK (version 4.11.0.0).

    I am not able say what pin is a best candidate for NWP log connection. This must determine only you, because I don't know how your hardware works.

    I don't know how TP4057 works and I found datasheet only at Chinese, which is not usable for me. It seems that T4057 pins CHRG and STBY works as output but I don't know if they can be left NC. If not you can cut a PCB trace into CC3235. Another good candidate may to be pin 18 (LED2). Maybe you can directly solder wire directly to your LED. For more details please ask person which created schematic for your hardware.

    Jan

  • Hi wu,

    maybe last thing before we try to enable NWP logs, i want to make sure whether the EAGAIN error is truly coming from the NWP or maybe from the host driver itself.

    There is a global variable in the host driver referred to as g_pCB that holds some useful configuration.

    Can you print the values of the following parameters each time you call sl_Send()?

    • g_pCB->FlowContCB.MinTxPayloadSize
    • g_pCB->FlowContCB.TxPoolCnt

    Also let me know what is the length of the packet that you are trying to send.

    Regards,

    Shlomi

  • Hi,

    Where is g_PCB defined? Why didn't I find the change when I looked it up? Each packet I send is 493 bytes long.

  • Hi,

    I don't know where g_PCB is defined, so there is no way to reference that variable to print the information you need.

  • g_pCB is part of the host driver and is defined as global under driver.c.

    The entire host driver which is the Wi-Fi device driver resides under source/ti/drivers/net/wifi in the SDK.

  • Hi,

    But I'm using the MQTT_client routine, which doesn't have driver.c

  • Hi,

    This is every time I call sl_send () print g_pCB - > FlowContCB. MinTxPayloadSize and g_pCB - > FlowContCB. TxPoolCnt