FreeRTOS Plus TCP wrong frame size with BufferAllocation_1.c

Libraries
1

Hello there,

I’ve spent some time debugging my TCP implementation. I’m using TMS570LC435 copy Ethernet driver for FreeRTOS**+**TCP V4.3.2 and static buffer allocation (BufferAllocation_1.c).

To test the integration. I implemented a simple echo server. When testing it the TCP handshake worked fine, but afterwards no payload was transported.

For me it seems like the error is in src\os\freertos\freertos-plus\freertos-plus-tcp\source\FreeRTOS_TCP_Transmission.c:prvTCPBufferResize().

  • In prvTCPBufferResize() I have xBufferAllocFixedSize != pdFALSE as I’m using BufferAllocation_1.c so uxNeeded is ipTOTAL_ETHERNET_FRAME_SIZE
  • ipTOTAL_ETHERNET_FRAME_SIZE is ( uint32_t ) ipconfigNETWORK_MTU ) + ( ( uint32_t ) ipSIZE_OF_ETH_HEADER ) + ipSIZE_OF_ETH_CRC_BYTES + ipSIZE_OF_ETH_OPTIONAL_802_1Q_TAG_BYTES )
  • That equals in my case 1500

A bit later pxGetNetworkBufferWithDescriptor() is called with uxNeeded as xRequestedSizeBytes

  • This causes the check if( ( xNetworkBufferSemaphore != NULL ) && ( xRequestedSizeBytes <= ( ipconfigNETWORK_MTU + ipSIZE_OF_ETH_HEADER ) ) ) { to fail as ipconfigNETWORK_MTU + ipSIZE_OF_ETH_HEADER is in my case 1514.

My solution was changing FreeRTOS_IP.h to

#define ipTOTAL_ETHERNET_FRAME_SIZE ( ( ( uint32_t ) ipconfigNETWORK_MTU ) + ( ( uint32_t ) ipSIZE_OF_ETH_HEADER ) )

Now it works. Do you now a better solution to fix this?

Best,
Sven

2

I assume you are talking about this check which compares against uxMaxNetworkInterfaceAllocatedSizeBytes which is returned by uxNetworkInterfaceAllocateRAMToBuffers. Can you share your definition of uxNetworkInterfaceAllocateRAMToBuffers from your network interface or share your compelete network interface implementation?

Modifying FreeRTOS_IP.h is not the right thing to do. We can decide what is best once you share these details.

3

Thank you for your reply. It explained already a lot. It was a bug that was already fixed in the release of V4.3.3.

4

Thank you for reporting back!

5

When is this BufferAllocation_1.c fix going to be applied to an LTS release, as the current LTS release still references V4.2.6? I’m using the STM32H7, and I’m not even receiving ARP replies because RX buffer allocation is failing. See past bug issues #1276, #1285, etc. Thanks!

6

As I see on this page, the current LTS is pointing to 4.4.1: FreeRTOS LTS Libraries - FreeRTOS™.

7

Huh, Oh Ok, guess I was looking at the wrong branch then… FreeRTOS-LTS/FreeRTOS at 202604-LTS · FreeRTOS/FreeRTOS-LTS

8

What STM32 HAL version does the 202604-LTS release utilize? I probably need to update my STM32 driver files to match the driver version used in this release. Still using V1.9.0 which is quite dated. Is this documented anywhere? Thanks!

9

I do not think there is a dependency on the driver version. I’d use with the latest or with whatever you have. Let us know if you face any problem.