Hi @htibosch, I am runing the latest FreeRTOS v202112.00 and am having the same issue, where tx_release_[3] is not 0. tx_release_count[0] and [1] are both always matching. I am running the NetworkInterface.c from the DriverSAM, along with the gmac_SAM.h/c files.
I have been trying to track down the issue, but I cannot figure out exactly when a TxBufferDescriptor semaphore is not being released. When I launch my software, it all works. The issue only starts happening after I send a command to the microcontroller to send me a lot of data. So it really just sounds like the Ethernet stack is getting overwhelemed, but I’d expect for all the packets to be sent/receieved after a while and everything to settle down, however once tx_release_count[3] starts incrementing, my board just stops responding.
I am using a SAME70 processor on a custom board. Here are some of the IPConfig macros, I’m including all the ones that I think might be relevant:
#define ipconfigZERO_COPY_RX_DRIVER (1)
#define ipconfigZERO_COPY_TX_DRIVER (1)
#define ipconfigNUM_NETWORK_BUFFER_DESCRIPTORS 14
#define ipconfigETHERNET_MINIMUM_PACKET_BYTES 60
#define GMAC_RX_BUFFERS (8)
#define GMAC_TX_BUFFERS (4)
If I double the number of GMAC_TX_BUFFERS it appears to work most of the times. It scares me though that if I ever get close to the maximum number of buffers, after a few days or maybe weeks, then I’m done.
Any thoughts or ideas on figuring out where it’s going wrong? Once tx_release_count[3] starts going up, should it not fix itself?
My thoughts are that the there is a race condition with xNetworkInterfaceOutput and GMAC_Handler. Almost like multiple packets are being sent too fast and xTxCallback is not getting hit for each packet sent out and so there’s a BD leak.
Thank you for your time.