FreeRTOS+TCP ATSAM4E receive not working

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 ethernetphy.c from ASF to make some minor modifications so that they’ll play together. Basically an extra include and declaring ethernetphy_addr a global. So, transmission seems to be working. Atleast so well that a DCHP DISCOVER is sent. If we remove the “#define ipconfigDRIVERINCLUDEDTXIPCHECKSUM 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 vApplicnetworkinterface.prvRxCallback (ulStatus: 2) networkinterface.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 networkinterface.prvRxCallback (ulStatus: 2) networkinterface.prvRxCallback notified xEMACTaskHandle prvEMACHandlerTask RX event prvEMACRxPoll sending struct to IP task prvEMACHandlerTask packet received networkinterface.prvRxCallback (ulStatus: 2) networkinterface.prvRxCallback notified xEMACTaskHandle prvEMACHandlerTask RX event prvEMACRxPoll sending struct to IP task prvEMACHandlerTask packet received networkinterface.prvRxCallback (ulStatus: 2) networkinterface.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

FreeRTOS+TCP ATSAM4E receive not working

We’ve kept adding debug statements and can see that even prvProcessEthernetPacket in FreeRTOSIP.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 ipARPFRAMETYPE or ipIPv4FRAME_TYPE.

FreeRTOS+TCP ATSAM4E receive not working

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 ipconfigPACKETFILLERSIZE 2). The GMAC has to be configured accordingly. For instance, we call gmacsetrxbufferoffset(GMAC, ipconfigPACKETFILLERSIZE); in prvGMACInit in the network interface.

FreeRTOS+TCP ATSAM4E receive not working

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