Teensy 4.1: Ethernet and crossover cables

[squidzila]

I apologize if the question has already been asked but I cannot seem to find a solution. I am quite new with all this.

I currently have a Teensy 4.1 card with an ethernet shield. I am trying to connect it with ethernet to my laptop, through a (non crossover) cable an ethernet to usb c adaptor. The system previously functioned quite well with a different adaptor, but no longer works with my new one (I assume that the previous one supported auto mdix, but the new one does not). Windows does not even consider there to be a cable connected (Network cable unplugged).

My assumption is that this problem is due to this lack of crossover cable. However, the datasheet says that the ethernet chip is DP83825 PHY, which supports auto mdix.
My questions are:

1) Would this lack of crossover cable/auto mdix explain why Windows doesn't even consider that a cable is connected? Or could you see another reason?
2) If the ethernet chip does indeed support auto mdix, is it activated by default?
3) How could I check whether it is activated? How could I activated if it is not?

The chip's datasheet says that a register can be modified to switch the mdix/mdi mode. The only information I have found regarding this register is in the NativeEthernet library, where a comment indicates that the "IOMUXC_SW_PAD_CTL_PAD_GPIO_B1_11" register controls this. But I have no idea which values mean what.

Note: Cables and adaptors have been tested and work fine (when connecting to a router)

 

[PaulStoffregen]

Indeed DP83825 does support Auto-MDIX. It's inside the chip on Teensy 4.1, not part of the ethernet kit which adds the magjack.

Auto-MDIX is enabled by default. You can test it by starting with a known-good system using a regular cable, and then swap it with a crossover cable.

While not necessarily guaranteed to work, usually you can plug the 6 pin ribbon cable in backwards and communication will typically work anyway because Auto-MDIX figures out the RX & TX pairs are swapped, and the coupling through the LED to GND is far from ideal but often good enough.

 

[squidzila]

Thanks for you reply. Sadly, I do not currently have a crossover cable so I cannot test it. That said, given that all other parameters seem to work fine (ethernet cable, adaptor, teensy can connect to the internet through a router), do you have any idea what other kind of problems it could be due to?

Would it be possible to force ethernet into crossover mode, just to test it out?

 

[PaulStoffregen]

do you have any idea what other kind of problems it could be due to?

Are you sure that new ethernet to usb c adaptor really works?

Would it be possible to force ethernet into crossover mode, just to test it out?

Theoretically, yes, this is possible. Or at least I believe it is possible based on the documentation. I have not personally tried it.

As a practical matter, you would have to write special low-level code to configure the DP83825 chip. Adding freshly written untested code to a situation where you're already struggling to diagnose a problem without access to both types of cables is probably a path to only greater uncertainty.

But to answer in more detail anyway, I believe this info from page 20 in the DP83825 datasheet is probably what you're seeking

Auto-MDIX can be enabled or disabled in hardware, using the hardware bootstrap, or by register configuration, using bit[15] of the PHY Control Register (PHYCR, address 0x0019). When Auto-MDIX is disabled, the PMA is forced to either MDI (“straight”) or MDIX (“crossover”). Manual configuration of MDI or MDIX can also be accomplished using register configuration, using bit[14] of the PHYCR.

The PHYCR register is documented on page 62-63.



If you were to edit the ethernet init code to write to PHYCR, at least by my understanding of the documentation it should disable Auto-MDIX and let you manually choose which type of cable.

Hard to imagine how this could really be useful, as Auto-MDIX is very mature which virtually all modern ethernet products support. But if you really want to manually control it, that is probably how you would do so.

 

[squidzila]

The adaptor definitely works (I am answering this using it right now!). I have actually tested it with all three that I have on hand.

Thank you for the information about the mdix. I definitely understand and agree with your concerns about trying to change things like that before using more simple tests. I have ordered a crossover cable but it will take time to arrive. In the meantime I am completely stuck.

I just don't see what else could be going wrong. It could be a computer problem, but then it would just be with the Teensy, as I have no trouble connecting my computer to other computers by ethernet, for instance.

 

[BriComp]

Where is your software?

 

[squidzila]

My code? This problem happens even before code, as windows hardly detects that a cable is plugged in if it is plugged into the teensy.

But I did try running some code, the NativeEthernet "ChatServer.ino" example. I configured my pc's ethernet's ipv4 ip to "192.168.137.1", and set up the server on "192.168.137.177". I made sure that the subnet masks matched. This worked fine with a previous adaptor (that I briefly borrowed from someone, and no longer have access too...).

The code runs fine on the teensy, without errors. It detects that ethernet hardware is there and detects the cable. However, any attempt to ping it or connect to it through sockets on Python fails.

I have tried looking at packets with wireshark. When I start the teensy program, something does happen, namely ARP probes every so often (see picture). During this time, Windows oscillated between "unidentified network" and "network cable unplugged".



I am not sure how relevant it is, but this only happens with one of the adapters I have. With others (otherwise fully functional), nothing happens and Windows never detects anything.

 

[BriComp]

I am not sure how relevant it is, but this only happens with one of the adapters I have. With others (otherwise fully functional), nothing happens and Windows never detects anything.

You think!!

Forum Rule: Always post complete source code & details to reproduce any issue!

You have only just done that wasting other peoples valuable time.

 

[squidzila]

You have only just done that wasting other peoples valuable time.

I do truly apologize if the problem is due to the code. Given that my computer did not even seem to detect the connection I thought it had nothing to do with code, thus decided not to post it as the problem happened before that. If the code is indeed the culprit, my bad, and I apologize for wasting your valuable time. Again, this is the code (IP is customized to what I configured on my PC, subnet mask is set to 255.255.255.0 like on my PC and MAC is set to the one given by this code).

You think!!

I do, but I am a bit out of my element so I might very well be missing something obvious. The cables and adapters allow me to connect to the internet through a router and to communicate with other computers, so I assumed they were "fully functional".

 

[BriComp]

It NOT only says post CODE it also says

& details to reproduce any issue!

I am pretty sure that this is the problem.

I am not sure how relevant it is, but this only happens with one of the adapters I have.
You think!!

If you had started this we would not have wasted our time

 

[squidzila]

Perhaps there was a misunderstanding.

I am not sure how relevant it is, but this only happens with one of the adapters I have. With others (otherwise fully functional), nothing happens and Windows never detects anything.

"This" refers to Windows detecting something instead of nothing at all. With all other adaptors, Nothing happens, nothing works. Again, the problem occurs with *every* adaptor.

 

[PaulStoffregen]

If you had started this we would not have wasted our time

Wow, this is overly hostile and downright rude.

He did essentially show us the code in msg #9, it turns out to be just one of the published examples with IP number edited for his LAN... which is what I had assumed when writing replies in msg #2 and #4.

Yeah, we do have the Forum Rule about showing complete code, which wasn't strictly followed to the letter. Would have been better if the code had been show, just to rule out anything unusual. But we also have (or should have) basic common sense and decency. This overly hostile commenting is really out of line.

 

[BriComp]

Yea I agree, but I can only put it down to a dose of the Lurgy that I am suffering from for the last few days.
Appologies.

 

[squidzila]

Briefly reviving this thread to update.

I have obtained a crossover cable: the problem remains the same. So you were right, it probably has nothing to do with the auto MDIX
I have also tried with other computers: same problem.


I also tried using the QNEthernet library with similar results (this code). It helps to corroborate what Windows is saying though.

When connected to a router (with DHCP determined ip):

Starting...
MAC = 04:e9:e5:0d:d7:31
Starting Ethernet with DHCP...
[Ethernet] Link ON
[Ethernet] Address changed:
Local IP = 10.4.105.251
Subnet = 255.255.255.0
Gateway = 10.4.105.1
DNS = 129.132.98.12
Starting server on port 80...done.



When connected to any non-router device for which the proper static ip has been configured:

Starting...
MAC = 04:e9:e5:0d:d7:31
Starting Ethernet with DHCP...
[Ethernet] Link ON
[Ethernet] Link OFF
[Ethernet] Link ON
[Ethernet] Link OFF
[Ethernet] Link ON
[Ethernet] Link OFF
...

You get the idea. Switches every second or so. It feels like a bad connection, but this occurs whatever the computer and whatever the cable or adapter (crossover or not). This leave (I think) only the Teensy board. But the Teensy board works fine when connected to a router.

I really don't know where to go from here. Any ideas what I could try to pinpoint the issue?

 

[shawn]

Fun fact: the link status is polled approximately 8 times a second in QNEthernet.

I’ve used many Teensy 4.1s with networking programs and haven’t seen issues like this, so I’m fairly certain it’s not likely to be the software. It sounds like a hardware connection issue to me. Some things to try (if you haven’t already; I’m just trying to make the list comprehensive):
1. Wiggle or hold the Ethernet cable on either or both ends. Do you see a change?
2. Make sure that the Ethernet kit ribbon cable is seated correctly on both ends and is in the right orientation. I’ve experienced connectivity issues when this is the case for me. It’s bitten me more than once.
3. Try a different brand of Ethernet adapter.
4. Try the same Ethernet adapter on a different computer. (If you haven’t already.)
5. Try a different cable. (Sounds like you’ve done this one already.)
6. Just for kicks, try using a static IP on the Teensy. Is there a change in behaviour? I’m suggesting this experiment because you said you had connected to a static-configured device, but the text you showed was the Teensy using DHCP. I want to actually rule out the software. (I have learned that no matter how confident I am, I can still be wrong about it not being the software.)

 

[shawn]

I just added a way, in QNEthernet v0.21.0, to check for the presence of a crossover connection.