Teensy 4.1 "Semi-Bricked" - It (Kinda) Works, Just Not With My Code

Are these issues documented anywhere?

Search this forum. While there are issues and questions about NativeEthernet, they don't include the kind of crash you were seeing. I think you'll find that the issue is not NativeEthernet per se, but something related to your initialization and/or use of it. I recommend looking at QNEthernet because it does solve some of the known issues with NativeEthernet, and the developer seems very motivated to help people who want to use it.
 
My gut feeling is you might be suffering from a power related issue. Teensy 4.1's processor alone at 600 MHz consumes about 100mA. The ethernet hardware consumes a significant amount of power. Adding a SD card can draw even more. It can quickly add up to about as much as USB can normally provide. By completely removing NativeEthernet, the ethernet hardware will remain in a low power disable state.

If you're receiving power from USB, the 2 main problems tend to be unpowered hubs and cheaply made long cables. Some cables have incredibly thin wires, so even if your PC or a powered hub can output 500mA or 900mA, Teensy might be getting less than 4 volts when it needs more current.

However, the MKL02 is supposed to monitor the 3.3V power and reboot everything if it drops under 2.9V. So why things are going wrong this way is hard to understand. It might be software afterall.
 
This thread has some of wrong assumptions about how the bootloader works. Maybe that's harmless, or maybe it's leading to wrong conclusions? So here's a quick attempt to clear up a few. Not sure if this will really help, but seems worthwhile to spend a little time writing...

The bootloader is implemented in a separate small microcontroller. So it's not like a traditional bootloader which can't do anything while not actually executing on the main processor. While your program runs, it sits there doing very little, but not absolutely nothing. There are 2 ways you can get into bootloader mode. One is the press the pushbutton. The other is with a specific breakpoint instruction (which you can find buried inside the USB code). When you click Upload in Arduino, a program on your PC tries to find the USB device of your Teensy and send it a request to reboot. If your code is still running properly, it will hear that request and execute the breakpoint instruction to get the bootloader chip's attention. So while your program is running, the bootloader chip is watching to check whether the main processor has gone into a special halt mode because of that instruction. The 7 or 9 blink you're seeing are (probably) because it wasn't able to access the JTAG port in the ways it needs to observe the processor's state. Generally those more-than-4 blink errors happen only while your program is running. Even when programs "crash", usually JTAG can observe the CPU state. Not many things really interfere with the JTAG, but one thing that absolutely does is rebooting the main processor. On many chips the JTAG still works even while the process is in reset, but these IMXRT chips have a variety of security measures which normally only come into play with secure mode, but JTAG access definitely stops while the process in reset and for some time after it starts up. Whether your code is somehow triggering a reboot, I don't know. It's almost impossible to say from only the available info. So instead, I'm just trying to clear up some possible misunderstanding, in hope that might help.
 
... and I attached a scope (a 100 MHz DSO)
...
Peace!

My gut feeling is you might be suffering from a power related issue. Teensy 4.1's processor alone at 600 MHz consumes about 100mA. The ethernet hardware consumes a significant amount of power. Adding a SD card can draw even more. It can quickly add up to about as much as USB can normally provide. By completely removing NativeEthernet, the ethernet hardware will remain in a low power disable state.

If you're receiving power from USB, the 2 main problems tend to be unpowered hubs and cheaply made long cables. Some cables have incredibly thin wires, so even if your PC or a powered hub can output 500mA or 900mA, Teensy might be getting less than 4 volts when it needs more current.

However, the MKL02 is supposed to monitor the 3.3V power and reboot everything if it drops under 2.9V. So why things are going wrong this way is hard to understand. It might be software afterall.

@jtwine - With enabling the NativeEthernet would your 100 MHz DSO do well to monitor the 5V and 3.3V lines of the Teensy to perhaps catch the power level and dip? Also monitor pin #24 as it seems to be held high whenever the MCU is held up by the bootloader MCU.

I was wondering about Ethernet startup and power - except it wasn't shown the Teensy ever started executing the Reset startup.c code.
 
Hi, just faced and solved the exact problem, (flashing seems to work, but running my programs show up 7x red blinking. the 15s button press does boot into blink demo...)

It seems definetly power related. For my board I have the VUSB/VIN bridge cut and fitted with a Shottky diode. Apparently the shottky diode fell off. For some reason the board still gets powered by USB, but probably quite inefficently. Restoring the diode solved the blinking issue, and program just load fine again.
 
Hi,
had the same issue with 8x (eight times) blinking. Seemed to be either bad solder joint near MKL02 or conductive dust (something we experienced in the past). A standard procedure of removing conformal coating, cleaning, adding CS Flux and resoldering around MKL02 (nearby caps as well) revived the Teensy.
BR, CK
 
Back
Top