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.
The Teensy 4.1 PCB's appear to be the latest revision with IC's matching the markings of:
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.
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.