FreeRTOS+TCP v3 PIC32 Issue

Hello,

I’m trying to update my FreeRTOS kernel and TCP version to latest.

The BufferAllocation_2.c file provided at:
FreeRTOS\FreeRTOS-Plus\Source\FreeRTOS-Plus-TCP\source\portable\NetworkInterface\pic32mzef\BufferAllocation_2.c has all sorts of complaints when compiling.

Has this file been updated for use with +TCP v3.x?

Conversely, is this even the correct file to use to implement BufferAllocation_2 on a PIC32MZ? I’ve been using BufferAllocation_1, but I see mentions of BufferAllocation_2 being suggested with +TCP V3+

Thank You,
Ben

Can you share the compiler output?

It should be possible to use BufferAllocation_2.

The pic32mzef port needs its own BufferAllocation_x.c. It is interwoven with the Ethernet driver for PIC32.

So I’m also curious about the messages that you get and solve them one by one. Please post the messages in ASCII form, not as an image.

Hello Hein,

Nice to chat with you again. Thanks for assisting!

Right off the bat, these three lines produce “no such file or directory”
#include “tcpip/tcpip.h”
#include “tcpip/src/tcpip_private.h”

#include “NetworkConfig.h”

The tcpip files are not found anywhere in the FreeRTOS or FreeRTOS+TCP git.

Are these includes referencing something like harmony or plib by chance?

Hein,

I should probably add that I am perfectly happy with BufferAllocation_1. Is there a reason that +TCP v3 carries a recommendation for BufferAllocation_2, or is continuing to use _1 perfectly fine?

I’m using a NetworkInterface and PHY handler that is not part of the freertos distribution, and my project doesn’t rely on plib or harmony (true bare metal) - For what I’m sure are obvious reasons, I absolutely do not want to include Harmony.

Ultimately, I would like to either continue using BufferAllocation_1, or implement a BufferAllocation_2 that works without dependencies.

Thanks!
Ben

Is there a reason that +TCP v3 carries a recommendation for BufferAllocation_2

I was not aware of that recommendation. Maybe the writer uses platforms with less resources.

I’m using a NetworkInterface and PHY handler that is not part of the freertos distribution

phyHandling.c is a well tested generic interface to 100 Mbps PHY’s. All you need to provide is two access functions for reading and writing.

I don’t know where files like “tcpip/tcpip.h” come from.
It sounds like you don’t need anything special in the BufferAllocation module.

I like BufferAllocation_1.c as well, provided that I have enough memory. Quite often my network buffer memory is not cached, where the heap memory is cached. That has advantages when doing DMA operations.

implement a BufferAllocation_2 that works without dependencies

Here is BufferAllocation_2.c without dependencies.

I was not aware of that recommendation. Maybe the writer uses platforms with less resources.

The recommendation is pretty prominent on the main git page of +TCP

phyHandling.c is a well tested generic interface to 100 Mbps PHY’s. All you need to provide is two access functions for reading and writing.

Completely agree, and normally I would use it. This is not a standard PHY, however, and beyond that, we’ve implemented cable diagnostics.

I don’t know where files like “tcpip/tcpip.h” come from.
It sounds like you don’t need anything special in the BufferAllocation module.

I found the files - they are a part of Harmony. :face_vomiting:

I like BufferAllocation_1.c as well, provided that I have enough memory. Quite often my network buffer memory is not cached, where the heap memory is cached. That has advantages when doing DMA operations.

Exactly why I’ve typically been using BufferAllocation_1.

Here is BufferAllocation_2.c without dependencies.

Compiling that file causes segfaults at vReleaseNetworkBuffer very shortly after startup - which is actually what lead me to the pic32 specific BufferAllocation_2.c

void vReleaseNetworkBufferAndDescriptor( NetworkBufferDescriptor_t * const pxNetworkBuffer )
{
BaseType_t xListItemAlreadyInFreeList;

/* Ensure the buffer is returned to the list of free buffers before the
* counting semaphore is 'given' to say a buffer is available.  Release the
* storage allocated to the buffer payload.  THIS FILE SHOULD NOT BE USED
* IF THE PROJECT INCLUDES A MEMORY ALLOCATOR THAT WILL FRAGMENT THE HEAP
* MEMORY.  For example, heap_2 must not be used, heap_4 can be used. */
vReleaseNetworkBuffer( pxNetworkBuffer->pucEthernetBuffer );

Perhaps it would be better to investigate why the generic BufferAllocation_2.c seems unhappy with PIC32?

Hello Ben, I just compared the two BufferAllocation_2.c files, and created a merged version:

BufferAllocation_2_pic32.c (24.5 KB). It has the best of both, but it is not yet tested.

investigate why the generic BufferAllocation_2.c seems unhappy with PIC32?

Are you also using the Harmony driver? Or do you use your own bare-meatal Ethernet driver?

Harmony has its own network buffers called TCPIP_MAC_PACKET.
The PIC32 version of BufferAllocation_2 combines the two types TCPIP_MAC_PACKET and FreeRTOS’ NetworkBufferDescriptor_t.

Hello Hein,

I am sorry it’s been so long - somehow I missed that you replied to this thread.

I’m using my own bare-metal driver. No harmony, no plib - the entire code base is bare metal.

I appreciate you creating that merged version, but thus far, I’ve seen no issue with BufferAllocation_1, and I prefer it for a number of reasons. I wish the reason BufferAllocation_2 was recommended with +TCPv3 was specified, but at least for now, I intend to stick with BufferAllocation_1

Thank you again,
Ben