Since I've ported +TCP, I've been chasing several issue (most caused by me and my xNetworkInterfaceOutput().)
With those behind me, I was having an issue with the ENET not transmitting some messages randomly.
I finially figured that the Ethernet buffer being passed via pxNetworkBuffer to the xNetworkInterfaceOutput() function did not meet the 8 byte alignment requirement of the ENET.
When the ENET is asked to transmit a buffer NOT 8 byte aligned it stalls and does nothing.
Tracing into the stacks source code I found the issue.
static void prvTCPReturnPacket( FreeRTOSSockett *pxSocket, NetworkBufferDescriptort *pxNetworkBuffer, uint32t ulLen, BaseTypet xReleaseAfterSend )
TCPPackett * pxTCPPacket;
uint32t ulFrontSpace, ulSpace;
/* For sending, a pseudo network buffer will be used, as explained above. */
if( pxNetworkBuffer == NULL )
pxNetworkBuffer = &xTempBuffer;
#if( ipconfigUSE_LINKED_RX_MESSAGES != 0 )
xTempBuffer.pxNextBuffer = NULL;
xTempBuffer.pucEthernetBuffer = pxSocket->u.xTCP.lastPacket; ISSUE!!!!!!!
xTempBuffer.xDataLength = sizeof pxSocket->u.xTCP.lastPacket;
xReleaseAfterSend = pdFALSE;
lastPacket happens to be an array internal to the socket.
Depending on the memory location that held the socket, lastPacket may or may NOT meet my 8 byte alignment requirement.
It may case - it did not and it causes the ENET to stall.
Let me know if you disagree -- but I've traced this buffer all the way to thexNetworkInterfaceOutput() and it is root-cause.
I am using BufferAllocation_1
I hope this helps.
Not sure how to fix it myself other than to acquire a real NetworkBufferDescriptor_t and copy the contents of lastPacket into it.
Hein informed me that setting config flag: ipconfigZEROCOPYTX_DRIVER forces the stack to always use "Real" buffers.
Applied the config variable and all is fine.
Please note: there is absolutely ZERO information posted anywhere on the usage of the flag ipconfigZEROCOPYTX_DRIVER.
Hein has been a great help. All is well.