pbosscha wrote on Sunday, March 24, 2019:
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 (GMAC_USES_TX_CALLBACK, STACK_MACROS) 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?)
heinbali01 wrote on Sunday, March 24, 2019:
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() :
-uint16_t usGenerateProtocolChecksum( const uint8_t * const pucEthernetBuffer, BaseType_t xOutgoingPacket )
+uint16_t usGenerateProtocolChecksum( const uint8_t * const pucEthernetBuffer, size_t 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.
pbosscha wrote on Sunday, March 24, 2019:
It’s starting to work (PING/HTTP/FTP/CLI), was a little stupid about where to define GMAC_USES_TX_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 ul_size parameter from gmac_dev_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.
pbosscha wrote on Sunday, March 24, 2019:
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.