Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 16 of 16

Thread: Teensy 4.1 ethernet hardware failure

  1. #1

    Teensy 4.1 ethernet hardware failure

    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.

  2. #2
    Junior Member
    Join Date
    Sep 2020
    Posts
    19
    I can't answer your question but i was wondering about the linkstatus. I my case it always shows ''LinkOff''. My ethernet works but often it hangs.
    (see: https://forum.pjrc.com/threads/63373...server-problem)
    Do you use the example in nativeEthernet to check the link status ?

  3. #3
    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

  4. #4
    Junior Member
    Join Date
    Sep 2020
    Posts
    19
    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.

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,069
    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.

  6. #6
    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.

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,735
    @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?

  8. #8
    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?

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,069
    Quote Originally Posted by dmhummel View Post
    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.

  10. #10
    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.

    Click image for larger version. 

Name:	Analog_Ethernet_Teensy41.jpg 
Views:	26 
Size:	49.9 KB 
ID:	21961

  11. #11
    Junior Member
    Join Date
    Oct 2020
    Posts
    2
    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 by geraldt; 10-18-2020 at 10:41 PM.

  12. #12
    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.

  13. #13
    Junior Member
    Join Date
    Oct 2020
    Posts
    2
    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.)

  14. #14
    Junior Member
    Join Date
    Jul 2020
    Posts
    8
    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)...

  15. #15
    Member
    Join Date
    May 2019
    Location
    Colorado, USA
    Posts
    40
    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]);
    }

  16. #16
    Junior Member
    Join Date
    Jul 2020
    Posts
    8
    Hi KD0RC, I going to look into this example and implement it. I let you know how it works. Thanks!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •