• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 367 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.

Original question:

TMS570LC4357: EMAC Module Fails to Enter Receive Interrupt After Period of Data Reception with lwIP Protocol"

TMS570LC4357: Emac Polling at 100 mbit/s

Tyler Julian
Prodigy 20 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: LAUNCHXL2-570LC43, HALCOGEN

I am trying to achieve near 100 mbit/s on transmit and receive on the ethernet module for the TMS570LC4357 while exercising other functions of the chip. I have been using both custom hardware and the LAUNCHXL2-570LC43 for my implementation. I am able to get the data rate to 100 mbit/s, but the hardware is spending a lot of time waiting for the EOQ flag inside of the emacTransmit function.

/* Wait for the EOQ bit is set */
while (EMAC_BUF_DESC_EOQ != (EMACSwizzleData(curr_bd->flags_pktlen) & EMAC_BUF_DESC_EOQ))

I am sending a simple ping to the hardware and the hardware echos the packet after swapping source and destination.

I am trying to avoid the use of interrupts if possible and have been using halcogen whenever possible. Is there any advice or solution to reduce the amount of time spent waiting for the EOQ flag in emacTransmit? 

  • 0
    TI__Guru 69871 points

    Hi Tyler,

    Yes, I saw the discussion and there are potential Rx lockup conditions that pBuf is not freed fast enough while a new packet came in.

    There are some suggestions:

    1) increase the pBuf from 10 to a bigger one

    2) use the internal RAM for the pBuf

    3) modify the EMAC driver Rx ISR code to immediately release the pBuf.

    --

    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 20 points

    I am not locking up permanently and I'm not locking up in the Rx side of the EMAC and I am attempting to not use any ISR for this mode. I am spending the majority of the CPU time waiting for the EOQ flag to clear in the emacTransmit function.

  • 0 in reply to Tyler Julian
    TI__Guru 69871 points

    Hi Tyler

    Apologies for the delay in response.

    Tyler Julian said:
    Is there any advice or solution to reduce the amount of time spent waiting for the EOQ flag in emacTransmit? 

    I don't think there is any other way to reduce the waiting for the EOQ flag. If we eliminate this condition, that might potentially lead to the race condition described in TRM.

    --
    Thanks & regards,
    Jagadish.