T4.1 flashing another T4.1

M

mikemoy

Member
New to the teensy eco system. Got a T4.1.
I have one thing to confirm before moving on with it. We need the ability to update the firmware without using a PC / laptop. In the R.R. industry this is forbidden to install a tool on a PC without jumping through hoops to get it certified.
Thus I need to create a portable programmer. A simple handheld device with a pushbutton.
Can one T4.1 be connected to another and update the firmware ?
I.E. the first T4.1 with the .hex file on the uSD card will read it and flash the second T4.1

Is a solution like this or a device already out there ?
 
I'm currently working on a project that uses a Raspberry Pi Zero W to do over the air updates to a Teensy 4.0. I don't know if this approach would run afoul of your certification requirements as the Pi runs a Linux OS. The Pi could easily be made in to a handheld device, and with a display w/buttons from one of the many readily available add-on boards. My setup is such that I simply upload the hex file to the Pi and a Python script handles the rest, (using teensy_loader_cli from PJRC).
 
@Paul made a USB Host port programmer - seems it was in the Teensy 3.6 era?

Not sure if it was updated to work with T_4.1?

... and searching for the forum post or repository of Paul's just came up empty ...
 
The thread referenced by @thebigg provides a way to update firmware via a UART (or I2C or SPI) on the target Teensy, as opposed to via the USB connector, but it doesn't use the Teensy bootloader. It requires that the target include code to read/buffer/write the new program to Flash. Not sure if this would be allowed, but since the target is T4.1, you could just insert a uSD card with a hex file and let the target update itself. The RPI method from @DaveAK would use the bootloader, so would not require any special code in the target, assuming the connection is via USB.
 
joepasquariello said:
The thread referenced by @thebigg provides a way to update firmware via a UART (or I2C or SPI) on the target Teensy, as opposed to via the USB connector, but it doesn't use the Teensy bootloader. It requires that the target include code to read/buffer/write the new program to Flash. Not sure if this would be allowed, but since the target is T4.1, you could just insert a uSD card with a hex file and let the target update itself. The RPI method from @DaveAK would use the bootloader, so would not require any special code in the target, assuming the connection is via USB.
Click to expand...

Uart would be my preferred method. Not wiling at all to use anything RPI. Always out of stock and far to long boot times. Probably will wind up using an ESP32 as that is what I use currently to update my products.


Thanks guys for all the tips!!!
 
I totally understand about the RPi and on reflection for a handheld device the boot time is less than ideal. However, considering the other option mentioned where the target code is self-updating would a viable option be where the two devices run the same firmware and the programmer updates the target with its own code? Would save messing about with uSD cards which are a bugbear of mine. The idea would be that your base firmware has the updating code in it. New firmware would be developed and tested on the programmer, and contain this same updating code. When ready just connect UART and instruct the programmer to update the target with the code it holds. Or as @defragster suggests use the T4.1 programmer in USB host mode. Would that be faster than UART?

Just spitballin' ideas, not my project. :D Keep us posted on your solution.
 
HI @DaveAK.

"@defragster suggests use the T4.1 programmer in USB host mode. Would that be faster than UART?"

When I get more time to investigate, this is the option I would like best. I just have not had the time to look into it deep enough to see if it's a solution ready to go or that needs to be developed.
Currently slammed with trying to get USB host working on ESP32-S3 to connect a keyboard to it. The example for the T4.1 works great, but I am still a bit hesitant to continue with the T4.1. Not because there is something I don't like about it it seems awesome. I new to teensy, and to get caught up to speed with it will take more time than I have for this large project. I have been using ESP32 for years and know it well, and have many sources written to reuse.
My main concern with teensy (which I have never kept track of) is how often is it in stock, as this is a HUGE issue for our company right now.
 
Using T_4.1 USB Host port to program a T_4.1

Here is the year 2017 thread where Paul used a T_3.6's USB HOST to Program other Teensy units: Program-Teensy-from-another-Teensy

It has some evolution to program a T_4.0 - but Paul's code required T_3.6 for USB host programmer.

Next page Frank B in 2021 linked code that works using T_4.1 USB Host as programmer.

May take some attention to the Teensy ID recognition detection and storage of the proper HEX file on the Host Teensy:
Code: 
		case 0x24: return "Teensy 4.0";
		case 0x25: return "Teensy 4.1";
		case 0x26: return "Teensy MicroMod";

Seems to require Button Push on the Device Teensy to be reprogrammed to put it into recognized HID mode to program.
 
Thanks! I'm ok with the fact the user has the push the button.

I have to say being new to this forum, You guys here have been so helpful! Much more then other forums I go.
 
mikemoy said:
HI @DaveAK.

"@defragster suggests use the T4.1 programmer in USB host mode. Would that be faster than UART?"

When I get more time to investigate, this is the option I would like best. I just have not had the time to look into it deep enough to see if it's a solution ready to go or that needs to be developed.
Currently slammed with trying to get USB host working on ESP32-S3 to connect a keyboard to it. The example for the T4.1 works great, but I am still a bit hesitant to continue with the T4.1. Not because there is something I don't like about it it seems awesome. I new to teensy, and to get caught up to speed with it will take more time than I have for this large project. I have been using ESP32 for years and know it well, and have many sources written to reuse.
My main concern with teensy (which I have never kept track of) is how often is it in stock, as this is a HUGE issue for our company right now.
Click to expand...

USB Host programming will match or exceed the speed of UART or other - limiting factor may be the Flash write speed? But using the 'USB Host' mode of a 2nd Teensy will assure the bootloader chip handles the need programming as PJRC tests and intends with no extra code on the Device.

This page pjrc.com/store/teensy41.html show T_4.1 in stock at distributors - but not PJRC though:
Update, March 24, 2022: More Teensy 4.1 are in production, expected by April 26. Many Teensy 4.1 are still in stock at Digikey, Mouser, Adafruit, and other distributors.
Indications are the T_4.x IMXRT MCU's are more likely to be available from PJRC: The IMXRT chip is expected to be much less impacted by the global chip shortage.

T_4.0 is in stock and USB_Host is possible from that device - though requires some extra effort to present the HOST pins for use, versus the on PCB pin holes of a T_4.1.
 
defragster said:
Indications are the T_4.x IMXRT MCU's are more likely to be available from PJRC: The IMXRT chip is expected to be much less impacted by the global chip shortage.
Click to expand...

What's got me nervous is that I check the stock for the processor at digikey and mouser, and both are out of stock showing no estimates for when more will come in.
 
DaveAK said:
would a viable option be where the two devices run the same firmware and the programmer updates the target with its own code?
Click to expand...

@DaveAK, just FYI, that would work. The code doesn't have to be sent as Intel Hex records, so an application could read its own flash and build/send records containing address+data. I don't use Teensy-to-Teensy for updates, but I do something like that, which is to read the Intel Hex (text) file into an array that represents the target image, and then send address+data in a binary format. That's quite a bit faster when using a UART, and it avoids having to include the Intel Hex parser in the target.
 
mikemoy said:
What's got me nervous is that I check the stock for the processor at digikey and mouser, and both are out of stock showing no estimates for when more will come in.
Click to expand...

Is there less of an issue with ESP32? I've never used it, so I'm not familiar with the supply chain.
 
joepasquariello said:
Is there less of an issue with ESP32? I've never used it, so I'm not familiar with the supply chain.
Click to expand...

Anything could happen, but there are so many companies stocking them I double there will ever be an issue. Moreover, they have so many flavors to help too. Like I could be using the 4mb version in a product, and if I could not get any I could simply jump to using the 8,16,32 mb versions. Drop in replacements. It is my favorite chip of all time because it includes everything I will ever need in a product. Wi-Fi, BT, Ethernet, and its a dual core 240MHZ processor.

I will say I am intregued with the T4.1 it has much more speed, and peripheral stuff. Just dont know if I want to take the plunge without a valid working RTOS. I know people have ported their own, but they are not kept up to date, or are limited.
 
mikemoy said:
What's got me nervous is that I check the stock for the processor at digikey and mouser, and both are out of stock showing no estimates for when more will come in.
Click to expand...

It is not a good time to look to order things :( Nothing is guaranteed it only takes one missing 'widget' to stop PCB production. A friend building ESP32's saw the PICO D4 chip price jump $1 between prototypes - and other onboard parts jumped a small build some $2+ between orders for other parts.

Paul noted he ordered some T_3.x MCU's in Jan 2021 - they are hoped to be delivered later this year 2022 ... summer or fall ????

As indicated some IMXRT 1062's have recently been received at PJRC and are actively in production. T_4.0's still in stock at PJRC, and PJRC's T_4.1's just went GONE in recent week or so - but still in stock as noted at some distributors.
 
mikemoy said:
Anything could happen, but there are so many companies stocking them I double there will ever be an issue. Moreover, they have so many flavors to help too. Like I could be using the 4mb version in a product, and if I could not get any I could simply jump to using the 8,16,32 mb versions. Drop in replacements. It is my favorite chip of all time because it includes everything I will ever need in a product. Wi-Fi, BT, Ethernet, and its a dual core 240MHZ processor.

I will say I am intrigued with the T4.1 it has much more speed, and peripheral stuff. Just don't know if I want to take the plunge without a valid working RTOS. I know people have ported their own, but they are not kept up to date, or are limited.
Click to expand...

May I ask whether you use the ESP32 Arduino core, or the straight (non-Arduino) ESP-IDF?
 
joepasquariello said:
May I ask whether you use the ESP32 Arduino core, or the straight (non-Arduino) ESP-IDF?
Click to expand...


Sure, I mainly use ESP-IDF 99% of the time. The only time I don't is when someone has an Arduino library I want to use and I'm too lazy to convert it to IDF.
You get allot more control of things using ESP-IDF & the final compile output is much less. Not that it matters much to me because I use the 16MB version.
I have had issues in the past using Arduino with I2C. But in IDF never.

FWIW, if you use Arduino you can also use IDF in there as well.
 
mikemoy said:
Sure, I mainly use ESP-IDF 99% of the time. The only time I don't is when someone has an Arduino library I want to use and I'm too lazy to convert it to IDF.
You get allot more control of things using ESP-IDF & the final compile output is much less. Not that it matters much to me because I use the 16MB version.
I have had issues in the past using Arduino with I2C. But in IDF never.

FWIW, if you use Arduino you can also use IDF in there as well.
Click to expand...

Okay, thanks. I've experimented with STM32, but not ESP32, though I share the interest in built-in RTOS, and avoiding having to modify the core. I haven't tried Teensy Threads, but rather have settled on a very simple cooperative RTOS. It lets me re-use existing code and multi-thread designs from prior embedded projects, and it works with no changes to the Teensy core. You'll find repositories on my github named minicoop and minios, which are out-of-date, but pretty close to what I'm using now. My starting point for the context switch code was a repository named zilch by Teensy user @duff. There are lots of other cooperative OS for for ARM Cortex M, but one that I think is clearly documented is called CMCM, link below.

https://github.com/scttnlsn/cmcm
 
You must log in or register to reply here.
Back
Top