Found an issue with +TCP

Posted by joehinkle on 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( FreeRTOSSockett *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