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.

Ethernet not working on EVMOMAPL-137 based custom board - troubleshooting suggestions?

Hi

This might be a long shot, but I’ve got an Ethernet problem on a custom board and curious if anyone has any suggestions for troubleshooting.

 

We built this board based on the EVM OMAP L-137 board, with the only changes being getting rid of components we aren’t using (like the SD card slot), getting rid of one of the Ethernet jacks, and switching to a C6745 DSP instead of an OMAP L-137 (we are not using the ARM core), reducing the amount of RAM (for the 16-bit EMIF) and adding the codecs and analog audio electronics for our particular project.

 

Problem is that the Ethernet never sends or receives data packets. The EVMOMAPL-137 emac loopback test project (used with an Ethernet loopback cable) works and the test passes on the EVM board, but not on our board. According to the test code our board establishes and link and auto-negotiates (so we know the DSP and PHY are communicating this much), but fails to ever send out any packets. I know this by connecting either the EVM or our board to a PC via a crossover cable and using Wireshark to see what packets come in when running the emac_loopback test code that comes with the EVM OMAP L-137 board. The EVM’s packets are received by the PC, but those from our board are not. On our board, ethernet also fails to configure via DHCP or really do anything at all. It does not show up on our router or respond to data sent over the network, even when i give it a manual IP address that is within the subnet mask of the router.

 

We modified the code of the emac loopback (in emac_test.c) so we could see which tests are failing. The tests we are failing at are:

verify_packet( pDescBase, 60, 0 ) should be 0, but is 5

verify_packet( pDescBase + 1, TX_BUF, 0 ) should be 0 but is 1

EMAC_FRAME64 should be 2 but is 1

EMAC_FRAME128T255 should be 2 but is 1

EMAC_RXGOODFRAMES should be 2 but is 0


EMAC_TXGOODFRAMES is correctly 2

And the number of packets (first error test) is correct (ie pDescRx = (pDescBase + 2))


Our custom software using the NDK (version 2.0.0) exhibits similar behavior.

 

The only thing that we potentially see as a problem here is that our Ethernet jack (with magnetics) is located about 3” from the PHY chip on the board due to space constraints, which is farther away than it tends to be located on most designs, and we’re concerned this might be an issue. Could anyone weigh in if traces this long might make an Ethernet port completely inoperative?

 

But it might also be a communication problem between the PHY and the DSP – as I understand it packet data sent between the PHY and DSP travels on separate pins from info such as link status (which IS working) – so we’re also investigating the possibility of a problem between the DSP and PHY.

 

Does anyone have experience with this sort of thing – pointers about where to start troubleshooting, etc? We’ve checked and rechecked traces and wiring and tried changing the physical locations of the resistors between the TX+ and TX- and RX+ and RX- lines to the jack, etc, all to no avail.

 

We realize that once we’re working on our custom board it’s a whole different ballgame as far as getting answers on this forum, but we did duplicate the hardware and schematics on the EVM board pretty exactly for the DSP portion of the board, and we’re frankly a bit stumped as to how to go about finding our problem, none of us at our very small company being Ethernet experts.

 

Thanks!
Arvid

  • So we've found and fixed one problem (poor ground connection on the 50MHz oscillator for MDIOCLK), and now have intermittently working Ethernet - the emac loopback fails about 2/3 of the time and passes the other 1/3 of the time. The device now shows up on the network, but DHCP does not work (when running our custom software). I can occasionally connect to it over TCP/IP, but no data can be sent back and forth reliably, since I assume whats happening is 2/3 of the packets are being lost.

    The problem seems to be between the DSP and the PHY because if I configure the PHY as a loopback (so that it bounces any external packets back) all packets are echoed back properly - meaning the hardware between the PHY and the jack is probably OK. Tested this by running the emac loopback program on the EVM OMAP L-137 board connected to the custom board with an X-over cable and it always passes.

    Again, and suggestions of what to look at to troubleshoot further? Thanks in advance.

  • OK - Never mind - I figured it out. Ethernet working now.

    Turns out I thought the RMII 50MHz Clock pin in the pinmux was the INPUT for the 50MHz clock - so i had enabled it in the pin setup. Turns out its actually the OUTPUT, ---so I was driving out an additional 50MHz clock into the same circuit as the external 50MHz oscillator. oops. I can easily see how that would cause problems! Ethernet works now that I completely disabled that pin in the pin setup.

    Now off to debugging the next level of problems that have been uncovered by this success... :)

    And for the record, it seems you can successfully put your ethernet jack with magnetics 3 inches away from the PHY chip on a board.