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.

RTOS/TM4C1294NCPDT: Ethernet frames missing.

Part Number: TM4C1294NCPDT

Tool/software: TI-RTOS

Hi.

I use TM4C1294NCPDT chip in my Ethernet application. When I send  several(15) short(47 bytes) frames with a high frame's frequency (10-14 uSec between frames) from Host computer to my controller, the controller misses some frames. 

When I decrease frames frequency(make a little delay between the packets) the controller doesn't miss the frames.

I found, that frames are missed when they are moved from RX FIFO of Ethernet controller to RAM, by Ethernet's DMA. ("Missed Frame Counter" bits of EMACMFBOC register increases when I send these packets).

From chip's datasheet:

Missed Frame Counter - This field indicates the number of frames missed by the controller because of the Host Receive Buffer being unavailable. This counter is incremented each time the DMA discards an incoming frame. This counter is cleared when the DMA accepts frames.

 

What could be the reason?

Is there a restriction on "Inter Packet Gap" for TIVA?

 I use in my application  TI-RTOS and NDK networking stack. The Ethernet works 100 Mbps.

 

Thanks in advance.

  • Hi,

    What else is going running on the target?

    Todd
  • Additionally, what are your memory settings for the NDK? Can you try increasing the number of network buffers? For a detail description, please refer to this site: processors.wiki.ti.com/.../TI-RTOS_Networking_Stack_Memory_Usage

    Todd
  • Hi Todd.

    Thanks for response.

     My controller controls a panel with switches, leds etc. It generally receives data from Ethernet and sends it to keyboards/leds controller via I2C bus and vice versa.

    Thus the FW consists from one Ethernet socket, several Tasks and HWi(from I2C, ADC, GPIO). The EMAC interrupt has the highest priority.

    I tried to increase the number of buffers and it didn't help.

    It does not look like there are not enough buffers or overflow, because it only receives 15 short UDP packets.

     

    May be I should change some default settings in the EMAC's registers?

    What are reasons can be for "This counter is incremented each time the DMA discards an incoming frame"?

    Best Regards.

  • What are the priority of the interrupts in the system? You can see it with Tools->ROV->Hwi->Detailed in CCS.

    Can you isolate the test to just receiving the UDP packets?
  • May I note that this thread provides a good "learning vehicle" for those, "Not so critically involved."

    To vendor Todd's most recent focus, "Priority of (expected) multiple interrupts" - does the RTOS prevent configuring the "EMAC Interrupt" as, "Preemptive?"    In a "normal situation" (outside of an RTOS) this "preemption" insures the highest performance for interrupts so, "gifted."

  • Hi Todd.

    I removed from the application all things that I can. The result is the same, missed frames. Here is the remaining Hwi.

    I2C interrupts – send data to leds and faders, GPIO – receive data from switches.

    Can you explain me the mechanism of "Missing Frames"?  

    Best Regards

  • Hi IgDor,

    Can you look at the EMACSnow_private? Specifically at the rx/tx counts and dropped values. Since it is a static, you may need to qualify it in CCS. For example: ‘C:/ti/tirtos_tivac_2_16_01_14/products/tidrivers_tivac_2_16_01_13/packages/ti/drivers/emac/EMACSnow.c’::EMACSnow_private

    Also, can you add the EMACSnow.c file to your project and bump up NUM_RX_DESCRIPTORS and NUM_TX_DESCRIPTORS to a bigger number (i.e. 8 or 16). Rebuild your app and try it out. Note: since the driver source file is in your project, the one in the library will be ignored.

    Todd
  • Hi Todd.
    Thanks you so much.
    I added the EMACSnow.c file to my project, increase number of NUM_RX_DESCRIPTORS to 16 and it helped me.
    In truth, I didn't know that it possible to configure EMAC with EMACSnow.c file.

    Best Regards.

  • Todd,

    As poster added (both:)

    • EMACSnow.c file

    and

    • increased number of "NUM_RX_DESCRIPTORS"

    Is it not possible that, "simply increasing the number of such RX_Descriptors" - did the trick?

    Like this poster - I cannot recall (much/any) mention of   "EMACSnow.c" - would it not prove beneficial - to many here - if you would describe, "If & When" that file should be added - AND - what it's "general purpose & intent targets?"     

    Thanks your time/attention - might it be that this "EMACSnow.c" deserves better "promotion" (and description)?

  • IgDor,

    Adding EMACSnow.c into your project is a work-around. The goal of the driver to use it "as is" in the library. It looks like we should have either made the number of packets larger or allowed the driver to be configured to use N packets. I'm going to open an enhancement request to make the number of Rx/Tx buffers in the driver configurable. This seems like the best solution since applications with slow throughput probably don't want to use the extra memory.

    Todd