FreeRTOS+TCP ATSAM4E receive not working

zetter wrote on Saturday, July 21, 2018:

Hi,

I’m just getting started with FreeRTOS and FreeRTOS+TCP in preparation for a switch we’re making to ARM from Atxmegas. We’re basing our new board on the ATSAM4E with a KSZ8051MNL phy, so we’ve bought a SAM4E-EK to get started with the software while the design team is working on the new board.

We started off with the ASF example project for the SAM4E to demonstrate FreeRTOS with LwIP. It works really well, but we figured we might start using the FreeRTOS+TCP right away, since it seems better integrated with FreeRTOS. However, we can’t really get it working. Send packets seems to be working fine, but we can’t recieve anything. It’s probably some stupid beginners mistake we’ve made, but we can’t figure out what it is.

We created the porject in Atmel Studio to select the appropriate ASF (3.4) modules (GMAC, GMAC_RAW…). We copied the whole ASF folder from that project into our project where we’re using our own makefiles and the GNU ARM GCC toolchain (we’re mostyly using OSX and Ubuntu for development and don’t really like the IDE).

We also downloaded the latest FreeRTOS (10.0.1) and FreeRTOS+TCP and added that to the project.

We’re loading the GMAC, GMAC_RAW and PHY modules from the ASF files instead of the supplied FreeRTOS versions to be get the latest ones.

We’ve copied the NetworkInterface.c template from the ATSAM4E example in FreeRTOS+TCP and the ethernet_phy.c from ASF to make some minor modifications so that they’ll play together. Basically an extra include and declaring ethernet_phy_addr a global.

So, transmission seems to be working. Atleast so well that a DCHP DISCOVER is sent. If we remove the “#define ipconfigDRIVER_INCLUDED_TX_IP_CHECKSUM 1” we can even see the DHCP server responding with an DHCP OFFER in Wireshark. Our code does however not seem to pick it up. In fact, it doesn’t seem to pick anything up from the network. We’ve added some debug statements throughout the code, and we can see that some receive stuff is called when the DHCP server responds. The same happens if we set a fixed IP and ping the card. The packets does however seem to get lost on the way to the higher levels of the code, and we can’t really figure out why.

Here’s a log with the debug statements:


prvIPTask started
xGMACWaitLS: 1 (PHY 1) freq 120 Mz
creating EMAC taskprvEMACHandlerTask
Network buffers: 45 lowest 45
INFO (2010-01-01 00:43:21): ethernet connected with IP: 192.168.2.3 in vApplicationIPNetworkEventHook at src/services/ethernet.c:59
INFO (2010-01-01 00:43:21): Subnet Mask: 255.255.255.0 in vApplicationIPNetworkEventHook at src/services/ethernet.c:62
INFO (2010-01-01 00:43:21): Gateway Address: 192.168.2.1 in vApplicationIPNetworkEventHook at src/services/ethernet.c:65
INFO (2010-01-01 00:43:21): DNS Server Address: 192.168.2.1 in vApplicnetwork_interface.prvRxCallback (ulStatus: 2)
network_interface.prvRxCallback notified xEMACTaskHandle
prvEMACHandlerTask RX event
prvEMACRxPoll sending struct to IP task
prvEMACHandlerTask packet received
Network buffers: 43 lowest 43
ationIPNetworkEventHook at src/services/ethernet.c:68
network_interface.prvRxCallback (ulStatus: 2)
network_interface.prvRxCallback notified xEMACTaskHandle
prvEMACHandlerTask RX event
prvEMACRxPoll sending struct to IP task
prvEMACHandlerTask packet received
network_interface.prvRxCallback (ulStatus: 2)
network_interface.prvRxCallback notified xEMACTaskHandle
prvEMACHandlerTask RX event
prvEMACRxPoll sending struct to IP task
prvEMACHandlerTask packet received
network_interface.prvRxCallback (ulStatus: 2)
network_interface.prvRxCallback notified xEMACTaskHandle
prvEMACHandlerTask RX event
prvEMACRxPoll sending struct to IP task
prvEMACHandlerTask packet received


Any suggestions on what might be the issue or where to start looking? I attached the network interface and ethernet_phy drivers together with the FreeRTOS configs, but I’m not sure exactly what parts might be relevant to find the issue. As we’re quite new to FreeRTOS och FreeRTOS+TCP I guess it might as well be something basic as the config for the OS, other hardware initialization (allthough we’ve tried to compare it line by line to the working example with LwIP), or something in our adaptaion of the network interface.

Best regards,
Fredrik

zetter wrote on Saturday, July 21, 2018:

We’ve kept adding debug statements and can see that even prvProcessEthernetPacket in FreeRTOS_IP.c is beeing called. However, printing pxEthernetHeader->usFrameType there gives only the values 69 when we ping it, and sometimes 256 (I guess stuff from the DHCP server). None of those match ipARP_FRAME_TYPE or ipIPv4_FRAME_TYPE.

zetter wrote on Saturday, July 21, 2018:

Ahh, found it. For anyone who might have similar problems in the future:
FreeRTOS defines a two byte offset as a default config option in FreeRTOSIPConfigDefaults.h. (#define ipconfigPACKET_FILLER_SIZE 2). The GMAC has to be configured accordingly. For instance, we call gmac_set_rx_buffer_offset(GMAC, ipconfigPACKET_FILLER_SIZE); in prvGMACInit in the network interface.

heinbali01 wrote on Saturday, July 21, 2018:

Hi Fredrik, thanks for reporting this, and especially for explaining what the problem was.

A lot has been written about this +2 offset, for instance here:

https://sourceforge.net/p/freertos/discussion/382005/thread/b762e48b/?limit=25#5f2d
https://sourceforge.net/p/freertos/discussion/382005/thread/cc4d0b2a/?limit=25#b9e1
https://sourceforge.net/p/freertos/discussion/382005/thread/cc8075ef/?limit=25#c143