We have ported the FreeRTOS TCP stack to our platform. In order to test it we copied the UDP example from the demos in Github.
It’s nothing fancy, very simple server and client.
The problem
If I run the client task by itself, all good no problems
If I run the server task by itself, all good no problems
The problem happens when I try to run both tasks at the same time. I have a termshark terminal connected to my network. When I run the client by itself the 1st message out of my host is a ARP request for the correct address of the server (192.168.0.253).
But when I run both tasks at the same time, the same ARP request is now for 0.0.0.0.
However, when I talk to the server from another host (the one of IP addr 192.168.0.253), the ARP tables in the TCP stack are updated and now the client starts sending data to the correct IP address.
Why is this? Any explanations would be really helpful
I am using BufferAllocation_2.c, with the corresponding heap_4.c.
I know I’m not running out of buffers because I have a UDP server listening for messages, and in a LAN I can send about 5000 messages per second with 0 packets dropped and all data being valid, from another host.
I can also send the same amount of data from the MCU to the same host, again, on a LAN, with 0 packets dropped and no data corruption.
The device is the S32K344 automotive System on Chip from NXP semiconductors.
The driver itself is not “thread safe”. However, I was convinced that since the TCP stack is thread safe there was no need for my low level interface output to also be thread safe.
It looks like the device on 192.168.0.253 doesn’t not receive the reply from 192.168.0.217.
The strange thing is that x.217 is able to send a UDP packet, which is received by x.253
Who is calculating the checksum? The EMAC, the Network Interface module, or the IP-task?
Are checksums offloaded?
EDIT
x.217 is able to send a UDP packet
that should be an ARP packet, and ARP packets do not have their own checksum.