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.

TM4C1294NCZAD: TI-RTOS NDK MCU blocks forever at accept TCP/IP socket connection requests.

Part Number: TM4C1294NCZAD

Hello,

 

I am using the TI-RTOS NDK stack to connect from a PC to a TM4C129 microcontroller over a TCP/IP socket connection. I am using a socket test app on the PC side.

 

I am able to establish connection when the PC is the server (accepts connection from the microcontroller) and the microcontroller is the client (uses the connect API).

 

However, when the PC is the client (attempts to connect to the microcontroller) and the microcontroller is the server (creates socket, binds, listens, then tries to accept), the microcontroller blocks at the accept() function and never sees a connection request from the PC.

 

Is there something in my code below that could be causing this? The only difference between this code and the TI example application (enet_tcpecho_server_tirtos) is that I am configuring my microcontroller to be using a static IP instead of being assigned one via DHCP. Could this have something to do with the problem?

 

Notes:

  • Program below blocks at accept and never prints "Accept socket success" (does not hit break statement either).
  • I enabled local and remote TCP ports on my PC firewall to make sure it was not a firewall issue.

 

Microcontroller as the server code:

 

serverListenSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

if (serverListenSocket == SOCKET_ERROR)

{

break;

}

 

System_printf("Create socket success.\n");

System_flush();

 

memset(&localAddress, 0, sizeof(localAddress));

localAddress.sin_family = AF_INET;

localAddress.sin_addr.s_addr = inet_addr("192.168.1.20");

localAddress.sin_port = htons(50000);

 

status = bind(serverListenSocket, (struct sockaddr *)&localAddress, sizeof(localAddress));

if (status != 0)

{

break;

}

 

System_printf("Bind socket success.\n");

System_flush();

 

// TODO - Change maxcon argument to constant

status = listen(serverListenSocket, 3);

if (status != 0)

{

break;

}

 

System_printf("Listen socket success.\n");

System_flush();

 

// TODO - Accept connection from remote host

clientSocket = accept(serverListenSocket, (struct sockaddr *)&clientAddress, &clientAddressLen);

if (clientSocket == (int)INVALID_SOCKET)

{

break;

}

 

System_printf("Accept socket success.\n");

System_flush();

 

IP Address portion of Config File:

 

  • memset(&localAddress, 0, sizeof(localAddress));

    localAddress.sin_family = AF_INET;

    localAddress.sin_addr.s_addr = inet_addr("192.168.1.20");

    localAddress.sin_port = htons(50000);

     

    status = bind(serverListenSocket, (struct sockaddr *)&localAddress, sizeof(localAddress));

    You are binding to your local address which is wrong. You should reference the example where you would bind to any address (INADDR_ANY). 

    Your PC ( the client) should connect to the server (192.168.1.20).

  • Hi Charles,

    Thank you for your response. I switched to using INADDR_ANY in the same way as the example project but am still not able to connect. Do you have any other suggestions?

  • Hi,

     What is your client IP address? 

     Is the client on the same subnet as the server?

     How did you come up with 192.168.1.20? You need to make sure this IP address is not already assigned to some other node or otherwise a conflict can arise.

     Does the original example using the DHCP work?

     Can you show the wireshark output?

     Can you show your PC client application?

  • Hi,

    Thank you for your suggestions. My client (PC) IP address is 192.168.1.182. I have an Ethernet cable directly connected from the PC to the microcontroller.

    I am using the SocketTest app found online: ::SocketTest:: - Test My Socket (sourceforge.net).

    Here is the output I am seeing on Wireshark. In this example I had the microcontroller (server) IP address set to 192.168.1.181 and its port to 23. The microcontrollers MAC address is the 11:22:33:44:55:66 one. As you can see the mcu responds to the "who has" command with the "is at" command, but never goes any further. Have you seen this before? Any ideas what might be causing this?

    I can try using DHCP. Interestingly, the socket connection did work when the client/server were flipped around such that the microcontroller was the client, and the PC was the server.

  • Hi Robert,

      Can you report back using DHCP with MCU as the server? In another word, use the example as is without modification. Can you get it to work? If it works, it can rule out many variables such as the network, firewall or gateway issue. Your randomly chosen MAC address seems to be an universally administered and multicast but it is not a OUI assigned address to a company.  

  • Hi Charles,

    I tested the DHCP tcp echo server example project on the EK - TM4C1294XL evaluation kit which has a similar mcu, and it worked (PC was able to connect to the launchpad). It also worked in static IP mode. This seems to indicate an errant software configuration on the custom mcu. I am trying to diagnose that now.

  • Hi Robert,

      Glad you are making progress and thanks for confirming both static address and DHCP work on the LaunchPad. If the same firmware works on the LaunchPad then I tend to think there is some issue with the custom board. Make sure you have RBIAS pin corrected go GND through a 4.87k resistor. Please also compare the schematic between your custom board and the LaunchPad. 

  • Hi Charles,

    I figured out the issue. It was related to the MAC address of the microcontroller. I was setting the 1's place bit in the first byte of the MAC address. This was causing the MAC address to be configured as "multicast" instead of "unicast." The client (PC) was rejecting the packet frame from the microcontroller since it was configured as multicast. We want unicast for our setup.

    For example, the MAC address 11-22-33-44-55-66 did not work since the LSB of the first byte is one (0001 0001), but 00-22-33-44-55-66 and 02-22-33-44-55-66 both work since in binary the LSB of the first bytes are zero (0000 0000 and 0000 0010 respectively).

    I discovered this because as one of my test scenarios I set the MAC address to 0-0-0-0-0-0 and the connection worked. After digging into MAC address details further, I discovered my mistake of setting the multicast/broadcast bit.

    Hopefully this record can help anyone who experiences the same problem.

    Thanks again for your help.

  • Hi Robert,

      Glad your issue is resolved. This is inline with my earlier comment a multicast frame may be rejected. See below. I will bookmark this post so I can refer to others who may be reporting the same symptom. 

    Your randomly chosen MAC address seems to be an universally administered and multicast