Hi All, Started with the Labs version for SAM4E Xplained (which works), then upgraded all possible files to 10.2.0. This generates 2 warnings (GMACUSESTXCALLBACK, STACKMACROS) and 2 errors (usGenerateProtocolChecksum “too few parameters”, missing ulApplicationGetNextSequenceNumber) all of which I fixed. The result is something that compiles, but does not seem to do anything beyond blinking an LED. Did anyone get this working ? (How?)

Hi Peter, the Network Interfaces tend to receive less attention than they need. They’re always on the edge between the TCP/IP driver ( with generic code ) and the actual hardware. The drivers are part of the distribution, but they all borrow code from the chip manufacturers. During the last 2 years, the FreeRTOS+TCP library has become safer: many security issues have been fixed. One of the fixes required a check on the packet length of the data received. And so a parameter uxBufferLength was added to usGenerateProtocolChecksum() : ~~~ -uint16t usGenerateProtocolChecksum( const uint8t * const pucEthernetBuffer, BaseTypet xOutgoingPacket ) +uint16t usGenerateProtocolChecksum( const uint8t * const pucEthernetBuffer, sizet uxBufferLength, BaseType_t xOutgoingPacket ) ~~~ About GMAC_USES_TX_CALLBACK : it is obligatory to define this macro as 1. The alternative has not been realised or tested. A missing ulApplicationGetNextSequenceNumber: you could have googled that 🙂 This function is supposed to be provided by the application builder. Again it has to do with security: it helps against TCP spoofing. Every TCP connection starts with some randomly chosen Sequence Number, from both sides. This sequence number should be chosen as randomly ( unpredictable ) as possible. If not, a third party might break in and take over the TCP conversation. Well, WikiPedia will explain this in a much smarter way.

Did anyone get this working ? (How?)

Of course, yes, I have many positive reports from people using the SAM4E port of FreeRTOS+TCP 🙂 You are supposed to deliver and maintain a configuration file called FreeRTOSIPConfig.h, and also FreeRTOSConfig.h. In the latter you will find the static declarations of MAC address and IP-address. I recommend to start without DHCP ( #define ipconfigUSE_DHCP 0 in FreeRTOSIPConfig.h ), and use a fixed IP-address. Then try to ping your device. If ping does not work, start up a capture program like WireShark.

It’s starting to work (PING/HTTP/FTP/CLI), was a little stupid about where to define GMACUSESTX_CALLBACK. Eventually put this in “instance/gmac.h” as this is common between Networkinterface.c and gmac.c, but if there’s a better place to put it then I’m open to suggestions. w.r.t. the usGenerateProtocolChecksum() compile error, I fixed this by adding a length parameter to vGMACGenerateChecksum() , and using the ulsize parameter from gmacdev_write(). (If that’s wrong, let me know). Strikes me that this should be fixed, should I raise a Ticket or is everything very fluid anyway at this stage ? My status now is that I can do an FTP transfer precisely once OR an HTTP page precisely once, and after that the network seems to hang: no more responses to anything (PING/HTTP/FTP/CLI). It should be noted that I’m running without the onboard aditional SRAM as that’s how I want to run on my eventual target board, but then again the original demo works just fine in that mode.

Issue seems to be happening for large files only, trying to transfer a 32K file with either FTP or HTTP hangs things up. Transferring a 5K file many times using FTP continues to work just fine.