Teensy 4.1 ethernet hardware failure

Status
Not open for further replies.

dmhummel

Well-known member
I have recently started using the Ethernet capabilities of a teensy 4.1 with the PJRC ethernet Kit. I have two devices and one works as expected, but the other always fails, reporting no cable (linkStatus() == LinkOff). I have not done much with the non-functioning unit to have caused the problem, though I may have plugged supplied ribbon cable in backward at some point.

Is that enough to permanently break the ethernet hardware on the board? It otherwise seems to function fine.
 
I am using my own code, but it does use the native ethernet library, some code posted here to pull the device assigned MAC and connects using IP assigned by dhcp . Most importantly, it does work well (no unexpected hanging) on one teensy 4.1, but not at all on the other.

If you are using DHCP, make sure to call Ethernet.maintain() regularly
 
Can you ping the unit you think is broken ?
Out of nothing my ethernet stopped working. I can ping it but if i load the webserver example it hangs after one run.
 
I can assure you the ethernet PHY on every Teensy 4.1 is tested during the bed-of-nails test that checks all the pins. In that test, the 4 data pins and GND are connected via 22 nF capacitors to a Pulse H1102 ethernet transformer in the test fixture, which has the transmit output connected to the receive input on the other side the transformer. In the test, the PHY is configured to 100 Mbit full duplex. After link status is detected, a ping packet is transmitted and the test fixture checks that the PHY receives all of the bytes properly, exactly matching the transmitted packet. If link status isn't detected within 0.35 seconds, or if the packet isn't received, or if any byte in the received packet doesn't match the transmitted packet, the test fails and the entire Teensy 4.1 board is rejected.

The same test fixture burns the bootloader into the MKL02 chip, only after all the other tests pass. If your Teensy 4.1 is able to be programmed by Teensy Loader, that's a sure sign is must have passed this ethernet loopback test.

Of course it's possible the Teensy 4.1 could have been damaged somehow after that test, perhaps in some way where only the ethernet is affected but uploading and everything else seems to work.

It's also possible you're seeing some sort of hardware issue with the magjack or other components or the soldering of those parts.

While a software problem seems unlikely, maybe at least try running the NativeEthernet examples like WebClient. Assuming your LAN has DHCP, just a quick run of that example should be a very easy test to confirm the problem isn't with the custom software.
 
Thanks for sharing details on how the units are QA tested, very cool.

I just tried the web client example that prints a response from Google. This also did not work. I switched the ethernet adapter between the devices and found consistently one teensy worked while the other did not, so it is not the soldering on the magjack board or the jack itself. Of note, the green light on the jack never turns on for the teensy that is failing while it turns on almost immediately in the web client test on the working device.

Paul, I don't want to test this theory with my remaining working teensy 4.1, but do you think I may have damaged the board by plugging in the ethernet adapter backwards (flipping the ribbon cable on one end)? This is quite easy to do, so it would be worth noting if it is a risk.
 
@dmhummel - have you compared the T_4.1 soldering to that here : pjrc.com/store/ethernet_kit.html

Obviously one there works as soldered - but just to be sure nothing on the Teensy was displaced or bridged. Interesting the pins on that don't include power if the connector is rotated, except to the LED? - not sure what happens when the Rx and Tx swap. Would be good to know if that is expected to be a harmless act.

Wondering what a DVM should show on those pins?
 
I checked the soldering, it was clean ( I re-heated and wicked around the solders just to check ). If I connect the ribbon cable one position forwards or backwards, the R+ will go into the R- and T+ into T- .. perhaps that could cause damage?
 
do you think I may have damaged the board by plugging in the ethernet adapter backwards (flipping the ribbon cable on one end)?

It shouldn't damage anything.

I tested just now on a Teensy 4.1. Amazingly, it works when plugged in backwards. But the green LED won't light up. I believe it may be working backwards because my ethernet switch supports auto-mdix. Still, I'm a little surprised it works so well, since the transformer center taps are getting connected to the LED output.

Plugged it in backwards, uploaded WebClient, then correct and uploaded WebClient again and I repeated this process several times. WebClient ran every time and fetched the info from Google. Speed was approx 200 kbytes/second every time, both plugged in regularly and reversed.
 
I measured voltage across [R-,R+,T-,T+] during the DHCP handshake attempt when starting a TCP socket server. For this test there was no ethernet adapter connected, just the probes. Clearly a difference between the two.
The only other relevant fact I can think of is that I purchased the bad teensy right when the 4.1 was first released. The second one that works properly was purchased recently.

I am going to move on, but thank you both Paul and Defragster for taking the time to look into this mystery. Paul, I would be glad to send the teensy back to you if that was helpful.

Analog_Ethernet_Teensy41.jpg
 
Hi. I have a similar problem I think. I have a udp server I had been running fine on an UNO and ported over to the Teensy 4.1 after wiring up a magjack as described elsewhere in this forum. The server waits till it a receives a message from a client and then responds. The problem is there is no response. It is receiving the incoming message and appears to send a reply but nothing is going out on the wire. I suspect it is a hardware problem, perhaps a faulty Teensy?.

I am using a python client program running on a pc to send messages,. The two are connected over a single direct ethernet cable with a fixed IP address. I should mention that I tried pinging the server and it pinged back - which surprised me. Is there a possible explanation for this kind of behaviour? I also used wireshark to confirm that no message is being sent by the server...

Code can be provided if necessary. I assumed there is no problem there though, since it worked ok before. Or is that being naive?
 
Last edited:
This sounds like a different issue, and potentially a software one. In my case, it is not possible to start a server and it always indicates it is not connected to a live ethernet cable. I recommend trying some of the c++ test examples to see if the client and server ones work.
 
dmhummel Out of interest I tried the "LinkStatus" example. It tells me my teensy status is OFF. What does that even mean?

Despite this, mine actually works ok now BTW. Initially I had a bad solder joint - then it was the string format I used that was being rejected silently. (I used the Example "UDPStringSendRecieve" as a code base, but had tried receiving/sending longer strings in XML format.)
 
Here I also have an issue with the Ethernet.LinkStatus(), it always shows "OFF" when the board startup and with the provided example from the NativeEthernet library.

Only after Ethernet.begin it shows the correct value. I use NativeEthernet library with the Teensy 4.1, this is the way to go?

The problem is that I need to see the LinkStatus before the Ethernet.begin because when the cable is unplugged the board crashes when the Ethernet.begin is called (No DHCP)...
 
Hi Jake,
Here is how I use NativeEthernet. I can get a connection whether there is a DHCP served address or not. It does rely on me hardcoding a known good address in the event of no DHCP. In my case, I get that address from a parm on the SD card so I don't have to recompile if the static address changes.

/*********************** getIpAddress *********************/
void getIpAddress()
{
// start the Ethernet connection:
Serial.println("=== Waiting for IP address");

teensyMAC(mac); // Get MAC address from Teensy

TimeIt = millis();
while (Ethernet.begin(mac) == 0)
{
if(millis() - TimeIt > 10000) // Five seconds to get a DHCP served address
{
Serial.println("Failed to configure Ethernet using DHCP");
getFixedIpAddress();
break;
}
}

addr=String(Ethernet.localIP()[0]) + "." +
String(Ethernet.localIP()[1]) + "." +
String(Ethernet.localIP()[2]) + "." +
String(Ethernet.localIP()[3]);

Serial.print("IP address is: "); Serial.println(Ethernet.localIP());
}

/*********************** getFixedIpAddress *********************/
void getFixedIpAddress()
{
IPAddress ip(Myip[0],Myip[1],Myip[2],Myip[3]);
// IPAddress gateway(MyGateway[0],MyGateway[1],MyGateway[2], MyGateway[3]);
// IPAddress subnet(MyMask[0], MyMask[1], MyMask[2], MyMask[3]);
// IPAddress ip(169, 254, 5, 25);
// IPAddress gateway(169, 254, 0, 1);
// IPAddress dns(169, 254, 27, 252);
// IPAddress subnet(255, 255, 0, 0);

// start the Ethernet connection:
Serial.println("=== Setting fixed IP address");

Ethernet.begin(mac, ip);
// Ethernet.begin(mac, ip, dns);
// Ethernet.begin(mac, ip, dns, gateway, subnet);

} // end getFixedIpAddress

/*********************** teensyMAC *********************/
void teensyMAC(uint8_t *mac)
{
for(uint8_t by=0; by<2; by++) mac[by]=(HW_OCOTP_MAC1 >> ((1-by)*8)) & 0xFF;
for(uint8_t by=0; by<4; by++) mac[by+2]=(HW_OCOTP_MAC0 >> ((3-by)*8)) & 0xFF;
Serial.printf("MAC: %02x:%02x:%02x:%02x:%02x:%02x\n", mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
}
 
Hi,
If you look on the library the linkStatus doesn't detect if a cable is connected or not, it detect if you have a response from the other side.
linkStatus is only modified when you call link_callback, function called on the ethernet.begin function, DHCP and Static IP
 
Status
Not open for further replies.
Back
Top