• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 487 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Concertif_receive randomly getting data length much larger than MSS configuration

Paul Roder
Prodigy 50 points

My last post didn't get any replies but I am continuing to investigate so please help if you can.  We are using LWIP with RAW TCP.  I have a test app that sends messages with large amounts of data using a .NET socket to the C2000.  All works fine, sending the same message sequences over and over, until randomly, the packet length reported in concertoif_receive is much larger than the MSS configuration.  Typically while running, the data len in the packet is the MSS size in lwipopts.h (1500, as in the TI example) + 20.  After running a while suddenly interrupt occurs where this number is way too large(ex and lwip pbuf allocation fails and everything messes up after that.  Should not this MSS size be negotiated at connection and never exceeded?  How could the board send through a packet with excessively large amount of data?  I am logging the socket output on the .NET app an nothing seems out of sorts.  Thanks, Paul

  • 0
    Prodigy 50 points

    Hello, is there any update on this problem from someone at TI?  Nobody responded and it still isn't solved and I would like to open up a case. Thanks

  • 0
    Guru 92251 points

    Paul Roder said:
    All works fine, sending the same message sequences over and over, until randomly, the packet length reported in concertoif_receive is much larger than the MSS configuration.  Typically while running, the data len in the packet is the MSS size in lwipopts.h (1500, as in the TI example) + 20.  After running a while suddenly interrupt occurs where this number is way too large(ex and lwip pbuf allocation fails and everything messes up after that.

    Can you clarify what you mean by "data len in the packet"?

    In the source code for concertoif_receive, the only length I can see is the (ethernet) packet length read from the hardware with

        /**
     * Obtain the size of the packet and put it into the "len" variable.
     * Note:  The length returned in the FIFO length position includes the
     * two bytes for the length + the 4 bytes for the FCS.
     *
     */
    temp = HWREG(ETH_BASE + MAC_O_DATA);
    len = temp & 0xFFFF;

     

  • 0 in reply to Chester Gillon
    Prodigy 50 points
    Thanks for responding Chester! Yes, exactly, len is way to large (much bigger than MSS) directly from the packet length from MAC_O_DATA. I put in a trap to discard the data when it is too long by disabling then reenabling Ethernet, but we still have occasional errors we cannot track down as these are very intermittent. As this data is coming right from the register, I have no idea how to track this down.
  • 0 in reply to Paul Roder
    Guru 92251 points

    Paul Roder said:
    As this data is coming right from the register, I have no idea how to track this down.

    Having looked at the Concerto F28M35x Technical Reference Manual I see that the MAC_O_DATA is reading from the RX FIFO. In order to keep synchronized with the received packets the software needs to read the length, and then all of the packet data from the RX FIFO. If for some reason one call to concertoif_receive doesn't complete read a complete packet from the RX FIFO, then the next call will read part of the packet 'data' as the 'length' which could cause the symptoms seen.

    I haven't get any hardware to investigate, but can you add a check that concertoif_receive completely reads all of the packet data in one go?