Hello everyone, I use FreeRTOS 10.1.1 to build a web server. In the ATSAM4E networkdriver usGenerateProtocolChecksum() complaines “too few arguments to function ‘usGenerateProtocolChecksum'”, size was missing. I added the size by taking it from gmac.c where it calls vGMACGenerateChecksum( ( uint8t * ) ptxtd->addr, ulsize ). So the call in network. c now is usGenerateProtocolChecksum( ( uint8t * ) apBuffer, ulsize, pdTRUE ), the size beeing the original size received in gmac.c. I’m mot sure if this is correct, but it won’t hit breakpoints set on errors in FreeRTOS_IP.c usGenerateProtocolChecksum. As there is no ATSAM4E demo included in version 10.1.1 I used as much of the demo 160919FreeRTOSLabs as needed. I got it all up and running and can with FTP I add the HTMLfordefault_pages to the disk. Now, when I request the freertos.html webpage, I get the web page, but without the logo and the ftp picture. Whireshark shows the full response for the freertos.html with an ACK after the HTTP OK. The Get /logo.jpg is still send, but the web server does not respond to it. I included the file wireshark10.txt with the wireshark info. Next I replaced the complete networkinterface folder with the folder from the 160919FreeRTOSLabs version. This time the server responds OK, I get the complete web page including the logo and FTP picture. the WireShark info is in the file wireshark9.txt Can anyone help me getting it running for the V10.1.1 version? Thanks in advance, Dik Hogendorf

Hi Dik, would you mind attaching the original PCAP files? Those are much easier to read than a TXT

Hi Hein, Thank you for the fast response. These are the pcap files from a new run. Digging in further I checked the txreleasecount in NetworkInterface.c after a run txreleasecount[0] = 0x08 (network buffers released?) txreleasecount[1] = 0x00 (no buffer selected?) txreleasecount[2] = 0x08 (Tx callback?) txreleasecount[3] = 0x17 (timeout waiting for free Tx descriptor?) so it looks to me as if it can’t get a Tx descriptor if I break on txreleasecount[ 3 ]++ txreleasecount 0 and 2 are both 0x08 kind regards Dik Hogendorf Van: Hein Tibosch Verzonden: maandag 18 februari 2019 16:29 Aan: [freertos:discussion] 382005@discussion.freertos.p.re.sourceforge.net Onderwerp: [freertos:discussion] FreeRTOS 10.1.1 HTTP server on SAM4E Xplained stops after sending one file Hi Dik, would you mind attaching the original PCAP files? Those are much easier to read than a TXT

---

FreeRTOS 10.1.1 HTTP server on SAM4E Xplained stops after sending one filehttps://sourceforge.net/p/freertos/discussion/382005/thread/758a0c06c3/?limit=250#7ee0

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/freertos/discussion/382005/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

About tx_release_count : – [0] must be equal to [2] – Both [1] and [3] must remain zero. txreleasecount[2] : After a packet was delivered, there is an interrupt from the EMAC. The TX DMA descriptors are returned via a queue ‘xTxBufferQueue’ txreleasecount 0 and 1: The task prvEMACHandlerTask() will free the Network Buffer. If the buffer was OK, it will call vReleaseNetworkBufferAndDescriptor() and increase txreleasecount[0]. Otherwise, it will increase txreleasecount[1] The above is only true for zero-copy drivers (ipconfigZERO_COPY_TX_DRIVER). Other drivers will only increase txreleasecount[0]. xTXDescriptorSemaphore is a “counting semaphore”, it keeps track of the number of available DMA descriptors for transmission. It is incremented after a DMA descriptor is returned to the driver. Have you seen this warning ? ~~~ FreeRTOS_printf( ( “TX DMA buffers: lowest %lun”, uxLowestSemCount ) ); ~~~ When txreleasecount[3] is increased, all DMA descriptors were occupied. That is unexpected. GMAC_TX_BUFFERS defines the number of DMA/TX descriptors. How is it defined in your project? But even if you only have 1 TX descriptor, there should not be a time-out: xNetworkInterfaceOutput waits for 50 ms for a TX descriptor. That is more than enough to deliver the largest packet. I think that your GMAC_TX_BUFFERS equals 8 and that xTxCallback() is never called by the driver gmac_SAM.c. Here you find the latest SAM driver, I attached it to this post I left in two lines that must be taken away: ~~~ -NVICDisableIRQ( GMACIRQn ); -NVICEnableIRQ( GMACIRQn ); ~~~ I temporarily disabled the IRQ in order debug the code. That might cause the problem that you are describing.