Teensy 4.1 - intermittent success when programming

SJFOM

New member
Hi all,

I've recently procured a batch of 20 x Teensy 4.1's from a reputable seller (Digikey) for a project I'm working on. I've been having mixed succes with the Teensy's ability to be programmed successfully each time I attempt to upload firmware using the teensy_cli_loader application (v2.2 - latest at time of writing). I've noticed that this behaviour seems to be dependent on the Teensy 4.1 MCU board I'm using at any one time with some Teensies having no trouble with programming upon each attempt while others will fail with some level of consistency. My early findings are that the majority of these boards show the intermittent behaviour described while only a minority show no errors.

Why does it matter?
My project requires a constant USB connection to the USB port of the Teensy 4.1 to allow for firmware uploads via a Linux host device (Raspberry Pi 4B). I'm using an I/O toggling mechanism to pull the RESET line of the Teensy 4.1 low for two seconds -> wait 2 seconds -> program using teensy_loader_cli application. It should be noted that I have used this exact mechanism with many Teensy 3.2's and 3.5's in the past without fail so have faith in its ability to work.

Specifics
I'm running the following command where echo-rev0-albatross.hex is the codename for my project device and is compiled using platformio with the Teensyduino framework. I'm making use of the -w and -v flags to both wait for the Teensy and gain verbose outputs when programming.
Code:
teensy_loader_cli --mcu=TEENSY41 -w -v echo-rev0-albatross.hex

The Teensy 4.1 PCB's appear to be the latest revision with IC's matching the markings of:

  • U1 = MIMXRT1062DVJ6B

  • U4 = NCV8186AMN330TAG

  • D1,D2 = BAS40-05V

  • U2 = GD32E230F8


Output data
I've attached two .txt files showing the outputs from both a "deemed working" and "deemed intermittent" Teensy 4.1 PCB using the teensy_loader_cli application on my laptop (MacBook Pro (16-inch, 2019) running MacOS Monterey running 12.5.1). In this experiment, I attempted to program a given Teensy 4.1 repeatedly while pressing the Reset button at different intervals to imitate poor timings on reset line behaviour in respect to when the Bootloader was actually ready for a new sketch upload. While this experiment was run on my laptop, it should be noted that the behaviour observed across Teensies is repeatable on Windows and Linux (Raspberry Pi 4B) and seems to be tied to the Teensy 4.1 hardware.


Take away
I appreciate that some form of retry mechanism would alleviate the above errors but I would really like to understand the reason behind this failure mode rather than ignore it given I do not have high enough conviction of N retry attempts always succcesfully programming a Teensy 4.1.

Really appreciate any help here, happy to answer questions and provide more info as needed.
 

Attachments

  • intermittent_t41.txt
    3 KB · Views: 28
  • working_t41.txt
    2.7 KB · Views: 25
Not used Linux or the CLI interface here - most don't.

Is the IDE installed? Does this behavior repro with the IDE - just for reference and verify it isn't an issue with the CLI process/timing/detection, versus T_4.1 hardware issue? Also TyCommander <link> might be worth trying for ref, and it also has a unique CLI version that may give different results.
 
I’ve noticed this happen to some of my boards as well. We have them soldered to a few dozen carrier boards and for us it seems to be related to the quality of the USB connection. For whatever reason, the CLI is more sensitive than other interfaces to the kinds of USB issues that don’t even show up on dmesg. I’ve found that after using shielded USB cables the likelihood of an upload failing was reduced. Haven’t yet looked too deep into it, I suspect if there was some kind of debug output for failed USB packet transfers you could have something show up when an upload fails. Maybe wireshark lets you scope this?
 
I also suggest that USB connection (wiring/connector/length) is bad, even if cable is good (have been there also)

T4.x run USB with 480 MHz while T3.x are running with 12 MHz
Suggest testing by forcing USB to run with 12 MHz

in cores/teensy4/usb.c uncomment

Code:
//USB1_PORTSC1 |= USB_PORTSC1_PFSC; // force 12 Mbit/sec

it is around line 211

Obviously, you must succeed to download the modified program to have effect for future USB activities
 
Many thanks for everyones input here. Ultimately I ended up using TyCommander's command line tool tycmd compiled on a Raspberry Pi 4B as this program yielded fully repeatable results when programming a Teensy 4.1. When compared side-by-side for the same Teensy 4.1 hardware attached over the same USB it would succeed 100% of the time in a repeated 100-run test whereas teensy_loader_cli would succeed around 50% of the time.

I did also try @WMXZ's great recommendation (thank you) of lowering the USB clock speed via this line but it unfortunately did not have any effect on programming success rates.

@linarism's comment on using high-quality shielded cables is definitely something I've also experienced and had pains in the past with. Currently using high-quality cables and the results are repeatable whether using >2m length USB cable runs or short 10cm USB cable runs - both of high quality.

One additional note is that, when programming using the Arduino IDE (v2.0.0 with included Teensyloader) I was able to program this Teensy 4.1 repeatably with no issues whatsoever. My take-away on this is that perhaps some particular timing requirement within the Teensy 4.1 is not always met with the teensy_loader_cli software (v2.2) on every attempt.
 
I've also found that increasing the teensy_write() timeout in the teensy_cli_loader can help with failed uploads. For the micromod, I had to increase from 0.5 to 2.0 seconds.
 
Back
Top