I have two different embedded devices with ethernet connection. One is based on Texas Intruments DM648 DSP chip and the internals of the other are unknown to me.

When I connect each one of them sperately to a PC, there is a connection.

When I connect them together, no connection is made. I have put a breakpoint into an emac link callback function, and the program did not stop there.

Could this behaviour be caused by incompatiable physical protocol? By incompatiale baud rate? Full duplex/half duplex incompatiabilty?

Can these things be software configured?

  • 2
    \$\begingroup\$ There's a million possibilities.. one is that a crossover cable is required. \$\endgroup\$ – Spehro Pefhany Nov 9 '15 at 19:57
  • 1
    \$\begingroup\$ Or that one has a buggy auto-negotiation that works with some peers but not with others. I have seen it happen. And so did others. \$\endgroup\$ – SX welcomes ageist gossip Nov 9 '15 at 20:02
  • \$\begingroup\$ I you can figure out what the other chip is, you can probably ask at networkengineering.stackexchange.com where someone might be familiar with them. \$\endgroup\$ – SX welcomes ageist gossip Nov 9 '15 at 20:07
  • \$\begingroup\$ I notice you accepted my answer as best, out of interest did any of my hints fix your problem and if so which one? \$\endgroup\$ – Peter Green Nov 12 '15 at 22:20
  • \$\begingroup\$ @PeterGreen, I left a comment to your answer. \$\endgroup\$ – Artium Nov 13 '15 at 10:46

Many older Ethernet PHYs do not support auto-mdix. Therefore the first thing I would try is changing the cable. If your current cable is straight through try a crossover, if your current cable is crossover try a straight through cable.

If that doesn't help then I would try looking at what speed and duplex mode they negotiate with the PC. In particular is it the same for both devices? This may provide some hints later when trying to find a configuration that works. If the PC is running linux you may also be able to use ethtool to look at the "link partner advertised link modes", that is what link modes your embedded device is advertising (however this doesn't always seem to appear,

Most Ethernet devices can have their speed and duplex settings controlled by software. Googling your operating system and/or platform name followed by "set speed and duplex" may help turn up some instructions. If they are Linux systems then "ethtool" can usually (apparently not all Ethernet adapter drivers support it) be used to either disable autonegotiation and force a specific speed and duplex mode or to leave autonegotiation enabled but restrict the modes that can be negotiated.

Note that having autonegotiation enabled on one end and forced full duplex with autonegotiation disabled on the other can cause a duplex mismatch which will lead to horrible network performance. If you want to use full duplex you should either use autonegotiation on both ends or manual configuration on both ends.

If you really can't get the devices to talk directly to each other you may have to workaround the issue by inserting a switch between them. Obviously this comes at a cost which may or may not be acceptable for your application.

| improve this answer | |
  • \$\begingroup\$ I was able to overcome the problem by connecting both devices through a switch. I am not sure what is the problem was. My guess based on your answer is that both cables of the devices (each device/pc connected to it's own cable and I interconnected these cable with a coupler) are crossed and coupling them together produce straight through. \$\endgroup\$ – Artium Nov 12 '15 at 22:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.