10.2.0+TCP on SAM4E Xplained
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?)
10.2.0+TCP on SAM4E Xplained
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.
10.2.0+TCP on SAM4E Xplained
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.
10.2.0+TCP on SAM4E Xplained
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.