Hello,

This is my first post on forum so first of all I want to say "Thank You" for the great job that you are doing with the FreeRTOS operating system. I started to use it due to the available features and excellent documentation provided.

I have a problem with server implementation from SimpleTCPEchoServer.c - in few words, does not respond to ping (and also arp) requests but even so at each 30 seconds it sends a "Gratuitos ARP" over the network.

Here are the details: FreeRTOS v9.0 FreeRTOS Plus TCP version 160919 Custom hardware based on ARM Cortex M7 (Atmel ATSAME70Q21) LogiLink USB to Ethernet adapter connected to PC - IP address 192.168.0.3 No DHCP (static IP - 192.168.0.2) No DNS

The initial software application contained FreeRTOS (without TCP/ IP Stack) and Atmel's Ethernet driver. This version responded to arp and ping requests thus I can exclude any hardware or network configuration issues. Then I added +TCP and the SimpleTCPEchoServer.c but no answers from board.

What can be wrong?

Regards, Andrei

The first thing to do will be to make sure the MAC is receiving interrupts for incoming packets, then if it is, follow the packet's path into the the stack to see how far it gets.

First though, I'm curious about the following from your post:

The initial software application contained FreeRTOS (without TCP/ IP Stack) and Atmel's Ethernet driver. This version responded to arp and ping requests thus I can exclude any hardware or network configuration issues.

If it didn't contain the TCP/IP stack, but did respond to ARP and Ping, what was responding to ARP and Ping. Was there a different stack in use that you removed? Or is there something in the hardware itself responding?

And in addition to Richards questions:

Sometimes the simplest things are the most complex. As far as I know we never provided a +TCP driver for ATSAME70Q21. Where did you get your driver? There may be many causes. Like Richard asks, do you ever get a DMA reception (RX) interrupt? Did you allow for broadcast messages in your EMAC?

Yes, MAC is receiving interrupts for incoming packets so I will have to check the path.

Atmel provided a mini TCP/ IP Stack capable to respond to ARP and Ping requests in order to test their MAC driver implementation. This mini TCP/ IP Stack and Ethernet drivers were implemented by Atmel for ATSAM4E and KSZ8051.

I updated the code to properly function with custom hardware build around ATSAM7EQ21 uC and KSZ8041TL Ethernet driver -> board responded to ARP and Ping requests (continuously tested for few hours without failures).

Broadcast messages are allowed by EMAC.

FreeRTOSIPInit() called before starting the scheduler; prvIPTask priority = 3 IPHook function -> network up -> create server task with priority = 1

Hi Andrei, I'm afraid I can't help you much more on this. Do you see that it attempts to send packets back? If not, you'll really have to follow the entire path from reception to answering. I'm not familiar with the mini IP-stack developed by Atmel. FreeRTOS has FreeRTOS+TCP, which has a driver and demo project for SAM4E. Unfortunately I don't have a ATSAM7EQ21 for testing.

Hello Hein, I think I was not so clear in explanations. Currently I am using the FreeRTOS+TCP with driver and demo project based on SAM4E but with some small updates necessary for ATSAME70Q21.

The mini TCP/ IP Stack provided by Atmel I initially use it just to test the EMAC driver, network configuration and possible hardware issues. After being confident that all things were well functioning I replaced the mini TCP/ IP Stack with FreeRTOS+TCP. Now comes my problem because the board does not respond to ARP and Ping requests.

It seems that TCP/ IP packets are not sent to IP Task due to pxNextNetworkBufferDescriptor which is NULL (prvEMACRxPoll function). Please have a look below.

	if( pxNextNetworkBufferDescriptor != NULL )
	{
		/* Point pucUseBuffer to the buffer pointed to by the descriptor. */
		pucUseBuffer = ( unsigned char* ) ( pxNextNetworkBufferDescriptor->pucEthernetBuffer - ipconfigPACKET_FILLER_SIZE );
	}

** else { /* As long as pxNextNetworkBufferDescriptor is NULL, the incoming messages will be flushed and ignored. */ pucUseBuffer = NULL; }**

I am trying to figure out why this is happening.

Which buffer allocation file are you using? BufferAllocation1.c or BufferAllocation2.c?

the board does not respond to ARP and Ping requests

Before being able to PING, an ARP request must be sent and answered. So let's focus at the ARP requests.

Do you see ARP requests arrive at your device? If not, did you allow for broadcast addresses?

If ARP requests do arrive, do you see that xNetworkInterfaceOutput() gets called? Do you see an answer to the ARP request on the LAN, when looking with Wireshark? If you do not see an answer, has the DMA been initialised well? Did you start the peripheral clock for DMA? Did you enable RX and TX? Were all descriptors well initialised?

If pxNextNetworkBufferDescriptor equals to NULL, that would mean that some Network Buffers do not get released. You're running out of Network Buffers.

Would you mind showing the adapted NetworkInterface.c ? You might also attach a PCAP if you want, when trying out an ARP / PING.

Regards.

I am using BufferAllocation_2.c

For an ARP request I don't see any network transfer with Wireshark but in debug mode if I store data received into a buffer (gsuceth_buffer) I can see the received packet, please see .png image and Wireshark capture.

For Ping request please see Wireshark capture named "Ping request.pcapng".

xNetworkInterfaceOutput () gets called For all the other questions the answers are affirmative.

... and in attachment it is the updated NetworkInterface.c source code

Hi Ion Andrei,

Your PCAP called "ARP request.pcapng" looks strange:

It shows 32 so-called gratuitous ARP requests, which are sent within less than a ms. The IP-stack will send these 'gratuitous ARP requests' regularly but not that often. The requests help other devices to keep ARP tables up-to-date, and also to help the detection of double IP-addresses.

Within "PING request.pcapng", I see three gratuitous ARP requests, sent at an acceptable frequency of two per minute.

The ping command (e.g. ping 192.168.0.2) will always start with an ARP command. In you PCAP, the ARP commando isn't answered by the device. As the device is sending gratuitous ARP requests, I would conclude that its RX path isn't working properly.

Hello Hein,

Related to ARP requests - after some time (dozens of seconds) the "gratuitos ARP requests" are sent at much lower frequency as you pointed out.

I'm fully agree that issue is on Rx path. Please have a look at first image with an ethernet frame received stored in gsuceth_buffer. All data bytes seems to be correctly received (e.g. ethernet header, ...) but aren't sent further to IP Task because all time pxNextNetworkBufferDescriptor == NULL and ~~~ As long as pxNextNetworkBufferDescriptor is NULL, the incoming messages will be flushed and ignored. pucUseBuffer = NULL; ~~~

~~~ > > It seems that TCP/ IP packets are not sent to IP Task due to pxNextNetworkBufferDescriptor which is NULL (prvEMACRxPoll function). Please have a look below. > > > > if( pxNextNetworkBufferDescriptor != NULL ) > > { > > /* Point pucUseBuffer to the buffer pointed to by the descriptor. / > > pucUseBuffer = ( unsigned char ) ( pxNextNetworkBufferDescriptor->pucEthernetBuffer - ipconfigPACKETFILLERSIZE ); > > } > > > > else > > { > > / As long as pxNextNetworkBufferDescriptor is NULL, the incoming > > messages will be flushed and ignored. / > > pucUseBuffer = NULL; > > } > ~~~

Please give me some hints about why pxNextNetworkBufferDescriptor equals NULL. What could be the reason for this? Thanks you.

Regards, Andrei