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.

AM3892: Ethernet Network Issue

Part Number: AM3892

Customer using EZSDK 5_04_00_11

The problem they have is that CPU does not receive an interrupt of reception of Ethernet packet on EMAC0 port.

During it, CPU can send a packet through EMAC0. The problem is only on receive direction.

We don’t know about EMAC1 because the production does not use it.


They checked register of EMAC0 and ARM Interrupt Controller module.

There is no difference between in bad condition and in good condition.


During the problem, the “ifconfig” shows something like below:


# ifconfig eth0

eth0      Link encap:Ethernet  HWaddr 00:0D:2E:00:00:20 

          inet addr:  Bcast:  Mask:


          RX packets:664765 errors:0 dropped:77 overruns:2883662 frame:2883681

          TX packets:193008 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:687965140 (656.0 MiB)  TX bytes:17466853 (16.6 MiB)

          Interrupt:40 Base address:0x8000


The number of RX packets never changes. The number of overruns increments every time.

And the data below is a dump of hardware statics registers.  The RXSOFOVERRUNS(offset 284h) and the  RXDMAOVERRUNS (offset 28Ch) is not 0.


ADDR 0x4a100200 0x003BA1FC 0x00014676 0x0000079C 0x00000000

ADDR 0x4a100210 0x00000000 0x00000000 0x00000000 0x00000000

ADDR 0x4a100220 0x00000000 0x00000000 0x00014B12 0x00000000

ADDR 0x4a100230 0xDA0F6BAF 0x00033E94 0x0002270A 0x00001DDC

ADDR 0x4a100240 0x00000000 0x00000000 0x00000000 0x00000000

ADDR 0x4a100250 0x00000000 0x00000000 0x00000000 0x00000000

ADDR 0x4a100260 0x00000000 0x012B3594 0x0005A28D 0x000A3B18

ADDR 0x4a100270 0x00059515 0x00017AD1 0x0001ED74 0x00260803

ADDR 0x4a100280 0xE0DC2B64 0x000001E0 0x00000000 0x000001F8


This issue can occur under heavy network traffic. There are variety of unicast, multicast, and broadcast on the network.

When there is a network loop, it looks it can increase a probability to cause this problem.

On the other hand, when they tried to reproduce this problem on test bench with simulator, they were able to cause “overruns counter”, but the EMAC0 never got stuck. It was able to communicate after removing heavy load.


Please advise an idea to investigate this issue.


Currently, there are 2 ways to recover the condition.

(1)    Software (Linux) reboot

(2)    Turn down the eth0 and up

(i.e) ifconfig eth0 down, then, ifconfig eth0 up.

  • Hi Lawrence,

    I can provide you the below hints:

    1. Try to reproduce the issue on DM816x TI EVM, thus will define if HW malfunction is observed on your custom board only. You can also run the emac_loopback HW diagnostic test on your custom board and check the result.

    2. Try to port your linux kernel with all the net/davinci_emac/network patches from the below GIT tree that do not exist in your code base:

    One example patch is the below one: