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.

Issue in receiving Ethernet packet- EMAC TMS320C6454

Other Parts Discussed in Thread: TMS320C6454, DP83640

Hi,

I have been trying to receive multicast packet from port 319.During this process only 40% of the packets are received.

I looked into network statics register of EMAC and observed that the RXCRCERRORS register was getting incremented for each failure in the packet.

I tried to look into the content of such packets captured in Wireshark but did not see any error.

Has anyone faced such problem before. And please let me know if CRC check can be bypassed in the EMAC.

Please advise me on this

Regards,

Pradeep

  • Pradeep,

    The primary focus of the Ethernet Forum is support for the TLK1xx and DP83xxx Ethernet Physical Layer products.  Based on the symptoms with the EMAC that you describe above, we may need to move your post to a forum where it will get the right visibility and support by the experts with the TMS320C6454 EMAC. 

    First though, in order to determine which forum will provide you with the support you need, could you provide me some information on the board you are using and specifically the Ethernet Phy that is connected to the EMAC?  Is this a board that you developed yourself or did you purchase the completed board?

    Patrick

  • Hello Patrick,

    The Ethernet Phy used is DP83640. Board development was done by us.

    Pradeep

  • Pradeep,

    I think it would probably be best to start with a review of the fundamentals of the design.  Could you provide a schematic of your design and a complete dump of the Phy registers?  If you are worried about posting  your schematics to the forum, let me know and we can make alternate arrangements.

    Patrick

  • Patrick,

    I have attached  EMAC and PHY part of the schematics:

    These are the dump of Phy registers

    anar = 0x0460;

    annptr = 0x2001;

    phycr = 0x8021;

    btscr10 = 0x090F;

    phycr2 = 0x2000;

    bmcr = 0x1220;7848.mac_phy_schematic.rar

    Remaing other registers retain default value

  • Hi,

    I have attached the schematics here5557.EMAC_PHY_Schematics.pdf

  • Hi,

    I looked into the wireshark file and what i said earlier was wrong.

    I tried to look into the content of packets which were dropped, in those packets there was no FCS added.

    I have used Wireshark to capture packets.

    Could someone please suggest me on this.

    Regards,

    Pradeep

  • Pradeep,

    I did not identify any major issues in a brief review of the schematic, but some of the text may be missing so some values are unclear.  Could you confirm the value of resistors used for R339 (VREF resistor) and RN11 (RX MII series terminations)?

    The register configuration is not necessarily incorrect, but certainly indicates an atypical application.  The settings for the BMCR, ANAR, and 10BTSCR must have been configured explicitly.  Could you provide some insight on the application?

    Where and how is Wireshark being used to view the packet contents?  Could you share the Wireshark pcap files for some of the dropped packets?  I would like to see if there is any pattern to the packets aside from the lack of an FCS.

    Patrick

  • Patrick,

    Value are as given below:

    R339 = 4.7K, RN11 = 33ohms

    The board is designed to work as PTP 1588 slave. I should be able to receive all the sync and followup message sent from the master. On the other hand i have another board configured as PTP 1588 master which sends the sync, followup messages and should be able to receive delay request message sent from the slave.

    For testing purpose i have connected the master and slave to a Ethernet switch. A PC is also connected to the swich for monitoring purpose, where packets are captured using wireshark.

    6646.PTP.rar

    Pradeep

  • Patrick,

    The issue is fixed. Few of the Decaps were not mounted and due to which the noise level at the input was high.

    Now there is no CRC error.

    Thanks

    Pradeep