• Content Count

  • Joined

  • Last visited

About DanielN08

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hello, I have found a solution to my problem which will be explained here. I have used Wireshark to analyze the networking packets on my WLAN. Debugging the C code in SDK showed that the TCP client socket was always in state 11, which means that the Pmod WiFi keeps sending the SYN packet to the TCP server. This is the first step required to start the three-way handshake in TCP protocol. More information about what is actually happening outside of the TCP Client could be obtained by using Wireshark. There are three main stages that need to be passed before actual data can be transmitted from the TCP Client to the TCP Server: DHCP (IP assignment to MAC address) ARP (MAC assignment to IP address) TCP's three-way handshake (SYN,SYN-ACK,ACK) These stages can be seen in the following capture from Wireshark: If we have a close look at packets 80 and 91, we can see that the TCP client's IP address (*.*.*.7) gets associated with MAC address 0:0:0:0:0:0 in the routing table defined by the ARP protocol. Afterwards, in packet 92 the Client is searching for the MAC address of the TCP server by asking for its IP (*.*.*.70). The server replies but it doesn't send the reply to the right MAC address, as seen in packet 93. The only way I was able to establish a connection between the server and client was by pinging the board's IP (client) from my laptop (server) via windows command prompt. Therefore, the C code of the client must be modified so that the correct MAC address of the Pmod WiFi is set in the routing table. This can be easily done by going into your SDK "BSP folder\ps7_cortexa9_0\libsrc\PmodWIFI_v1_0\src\DEIPcK\utility\DHCP.c" and uncomment line 725 "pLLAdp->ipStack.pARPIPv4->macDest = MACNONE;" and line 727 "pLLAdp->ipStack.pARPIPv4->macSrc = pLLAdp->pNwAdp->mac;". Changing the TCP client's C code has the following impact: This time the routing table will contain the correct MAC address of the client as seen in packet 257. Thus, the three-way handshake can be completed, and the payload can be sent to the server. The picture above shows that the TCP Server implemented in Python had successfully received the message from the FPGA sent via the Pmod WiFi TCP client.
  2. Hello Netanel, It sounds like I was having the same issue as you. I have found a solution to connect the Echo TCP client to any local TCP server. In SDK go to your BSP folder\ps7_cortexa9_0\libsrc\PmodWIFI_v1_0\src\DEIPcK\utility\DHCP.c and uncomment line 725 "pLLAdp->ipStack.pARPIPv4->macDest = MACNONE;" and line 727 "pLLAdp->ipStack.pARPIPv4->macSrc = pLLAdp->pNwAdp->mac;". The TCP client fails to connect to your local TCP server most likely because your TCP server receives an invalid MAC address (0:0:0:0) of the TCP client, changing those lines will attribute the correct MAC adress of the Pmod WiFi to your TCP server. I found this fix after spending a few days on it and reading the TCP packets in Wireshark. I will post a better explanation soon in my thread which can be found here: https://forum.digilentinc.com/topic/19647-cannot-use-the-pmod-wifi-tcp-echo-client-example/ I hope this helps, Daniel
  3. Hello, I am currently working on a university project where I want to record video frames using the Pcam 5MP and wirelessly transmit them via the Pmod WiFi to my laptop. I am using the Zybo Z7-20, Vivado 2017.4 and the Digilent vivado library from the master branch. My goal is to make a TCP server on my laptop and create a TCP client using the Pmod WiFi. In order to familiarize myself with the Pmod I have successfully implemented the following examples: HTTPServer and TCPEchoServer. In the TCPEchoServer example I have created a TCP client on my laptop using Python and I was able to send and receive simple messages like "Hello World", which were displayed in the serial terminal and echoed back to the TCP Client. I believe this shows that both HDL design and SDK project were correctly built. The SDK application is targeted to C++ and I do not have any compilation errors, just a few warnings. The HDL design is identical to the one in this post: https://forum.digilentinc.com/topic/17224-pmod-wifi-sdk-problem/?do=findComment&comment=52875 However, I could not run the TCPEchoClient C++ example. In this case I used Python to create a TCP Server on my laptop and I tried to connect the Pmod TCP Client to this server. Every time I run the example the serial terminal outputs the following: Serial Terminal Output This demonstrates that the Pmod WiFi is able to connect to my WiFi network, but it cannot establish a connection with the TCP Server. The "state" does change to "TCPCONNECT" but the application gets stuck in the TCPCONNECT case, because the if statement " if (deIPcK.tcpConnect(szIPServer, portServer, tcpSocket)) " never becomes true. The szIPServer and portServer variables were set according to the DHCP IP allocation obtained from my WiFi router as seen in the screenshot below. const char *szIPServer = ""; uint16_t portServer = DEIPcK::iPersonalPorts44 + 300; // Port 44300 Where DESKTOP is my laptop and Unknown is the Pmod WiFi. Parameters which match the IP:port values were set in my Python script for the TCP server, which can also be found attached here. Initially I thought that there might be an issue with the TCP Server, but I have downloaded a TCP Client app on my phone and using this I was able to send and receive messages from my phone to my laptop. Therefore, my laptop does not seem to block any inbound TCP connections. I have also used a TCP Server app on my phone and modified the szIPServer and portServer variables in SDK to match the new setup. Once again, I was unable to establish a connection between the Pmod WiFi TCP Client and the TCP server on my phone. Is the TCPEchoClient example only meant to work with the TCPEchoServer example? I cannot test this as I only have one Pmod WiFi. I would really appreciate any help with this issue. Please let me know if I forgot to include other vital information about my setup. Kind regards, Daniel EDIT: I have added a few print statements in the "DEIPcK.cpp" file, more exactly inside of the switch(tcpSocket._classState) of the tcpConnect() function. These print statements show that my application cannot leave the ipsInUseW case. I have found that this case means " // we are in use, may not be establised, but just waiting to be established" but I am not exactly sure how to proceed from this point as I do not really understand what is happening. It also appears that the state of the TCP socket is always equal to 11 (tcpSynSent) which was obtaiend from "pSocket->tcpState". EDIT2: I have also managed to connect my Pmod TCP client to google's server as done by the user in this post: https://forum.digilentinc.com/topic/19611-pmod-wifi-sdk-issues/?do=findComment&comment=53905. It seems like we both have the same issue where we cannot use the TCP Client to connect to our local servers. TCP_Server.py main.cc