joehinkle wrote on Friday, August 12, 2016:
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( FreeRTOS_Socket_t *pxSocket, NetworkBufferDescriptor_t *pxNetworkBuffer, uint32_t ulLen, BaseType_t xReleaseAfterSend )
{
TCPPacket_t * pxTCPPacket;
IPHeader_t *pxIPHeader;
EthernetHeader_t *pxEthernetHeader;
uint32_t ulFrontSpace, ulSpace;
TCPWindow_t *pxTCPWindow;
NetworkBufferDescriptor_t xTempBuffer;
/* 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;
}
#endif
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.
Joe