Hello there, I have a project using FreeRTOS TCP 160112 and it works really well. Today I tried upgrading it to 160919 and to my surprise it mostly is not working. I have been trying all morning to pinpoint exactly where is the issue for me but it is really difficult as, when I use breakpoints to find issues it tends to work. For example, I put for trace using SEGGER RTT message on input and output to get some kind of net trace and if I just let it run, a lot of packets are not even sent. If I put a breakpoint, voila, it stops and once I hit play they are sent. Before going crazy, are there any documented issues or changes I should do to NetworkInterface.c or to the config that I missed? Using the new version would be great for DHCP callback. Best regards,

There is a history file in the download that you can refer to. I would suggest starting with as basic a system as possible to get a simple system working first. For example, turn off DHCP and the name services and just a static IP address to check if pings to the static IP address are reliable, then work up from there.

Hello, It seems creating a socket too soon after the network is up is causing problems. Pinging the target for example works perfectly. If I use DHCP, it takes some seconds to get the DHCP lease and then it works. If I use a static address and try to do anything just after the network is up it fails. Is there any reason for this to happen? The taks that first connects to a server (DNS first, then TCP socket) waits until the network is up. Best regards,

Do you have the IP task at the highest priority?

The maximum priority is for the deferred receive task, and the second maximum for the IP task. Maybe the problem is opening the socket before the first ARP frames come in? I am not too TCP/IP savyy so maybe that is just stupid. Before, I just waited until the TCP/IP stack reported the network is up to create the task that attempted to connect to the server. Now I wait an additional 5 seconds before creating that task and it works well. If you need any more details please tell me. Best regards,

Sergio, What hardware / platform are you using? Each release has been tested on several platforms but we didn’t see a similar issue. These tests were done both with and without the use of DHCP. Some defines have changed (for aesthetic reasons), but the compiler will warn in case you’re still using earlier macro’s, e.g. :

#error ipconfigTCP_RX_BUF_LEN is now called ipconfigTCP_RX_BUFFER_LENGTH

Custom board with Infineon XMC4500. Yeah, I already checked those. Also, I tried removing the TCP window but just putting the macro to 0 gives me some errors as it seems there is some code trying to access a field that is removed without TCP window. In my project for now it seems solved, but if there is something you want to try to pinpoint it I can do that.