FreeRTOS 10.1.1 HTTP server on SAM4E Xplained stops after sending one file

dhogendorf wrote on Monday, February 18, 2019:

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( ( uint8_t * ) p_tx_td->addr, ul_size ).
So the call in network. c now is usGenerateProtocolChecksum( ( uint8_t * ) apBuffer, ul_size, 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 160919_FreeRTOS_Labs as needed.
I got it all up and running and can with FTP I add the HTML_for_default_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 160919_FreeRTOS_Labs 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

heinbali01 wrote on Monday, February 18, 2019:

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

dhogendorf wrote on Tuesday, February 19, 2019:

Hi Hein,

Thank you for the fast response.

These are the pcap files from a new run.
Digging in further I checked the tx_release_count in NetworkInterface.c after a run
tx_release_count[0] = 0x08 (network buffers released?)
tx_release_count[1] = 0x00 (no buffer selected?)
tx_release_count[2] = 0x08 (Tx callback?)
tx_release_count[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 tx_release_count[ 3 ]++ tx_release_count 0 and 2 are both 0x08

kind regards
Dik Hogendorf

Van: Hein Tibosch []
Verzonden: maandag 18 februari 2019 16:29
Aan: [freertos:discussion]
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

FreeRTOS 10.1.1 HTTP server on SAM4E Xplained stops after sending one file

Sent from because you indicated interest in

To unsubscribe from further messages, please visit

heinbali01 wrote on Wednesday, February 20, 2019:

About tx_release_count :

  • [0] must be equal to [2]
  • Both [1] and [3] must remain zero.

tx_release_count[2] :

After a packet was delivered, there is an interrupt from the EMAC.

The TX DMA descriptors are returned via a queue ‘xTxBufferQueue’

tx_release_count 0 and 1:

The task prvEMACHandlerTask() will free the Network Buffer.

If the buffer was OK, it will call vReleaseNetworkBufferAndDescriptor() and increase tx_release_count[0].
Otherwise, it will increase tx_release_count[1]

The above is only true for zero-copy drivers (ipconfigZERO_COPY_TX_DRIVER).
Other drivers will only increase tx_release_count[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 %lu\n", uxLowestSemCount ) );

When tx_release_count[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:

-NVIC_DisableIRQ( GMAC_IRQn );

I temporarily disabled the IRQ in order debug the code. That might cause the problem that you are describing.