A crazy idea for Teensy firmware updating

blackketter

Well-known member
One of the frequent requests on this forum is for a way to update teensy firmware from a source other than USB.

I wonder if it would be possible in a future version to the bootloader chip to provide a couple of external pins that provide a serial interface for firmware updates.

This could work like the ESP32 and ESP8266 serial boot loader, where there's a simple serial protocol for uploading and reset.

These pins could be brought out to bottom pads on a future teensy for use in a future PJRC board and be available to those designing Teensy-based systems that use the teensy boot loader chip.

As a side benefit use of these pins could provide a system reset facility and possibly even a JTAG over serial facility.

I realize that updating this way would be slower than USB, but might enable designs that otherwise wouldn't work with the current USB-only firmware load process.

Heck, I'd probably use two teensies (and two bootloader chips) in a design enabling a single USB port to program both (one directly and the other as a passthrough programmer).

Reactions?
 
You can search the forum for "OTA" to find my serial port firmware loader. It can use teensy serial port pins (or any other method of getting data to the teensy).

It would be nice if someone implemented gdbstub for the teensy.
 
Let us be realistic.
T3.6 had all pins available for SWD, and it needed only a "simple" modification in the bootloader chip to allow easy use of SWD. (lets ignore the HW solution discussed in the forum)
I say "simple", as I know if it where that simple, Paul would have done it.
Following the Teensy also for some time, I know changes in the Bootloader chip, are extremely rare and only done if really necessary.
So, the convenience changes of the bootloader firmware are extremely unlikely.
 
You can search the forum for "OTA" to find my serial port firmware loader. It can use teensy serial port pins (or any other method of getting data to the teensy).
I do remember seeing this before, it's excellent work. Well done!

I was throwing this out there to start a discussion about a way for Paul to be able to keep his business model of bootloader chips while fulfilling the needs of users who are needing to be able to program without USB. Paul's conservative approach that prevents bricking of devices by having the bootloader chip is also terrific and it would be great to be able to use that in non-USB designs. Add to this the ability to access the JTAG and chip reset, I think it would be a really compelling bit of functionality.

But no doubt a tough bit of engineering. If anybody could do it, it would be Paul. :)

It would be nice if someone implemented gdbstub for the teensy.
Agreed!
 
The whole point of the bootloader is not only to prevent bricking, but to prevent chinese clones from entering the market via normal hex uploading capabilities....
 
I'm absolutely in favor of Paul's business model and want to see it continue. But there is a market need for the ability to put a teensy in a sealed, in-the-field device and then update the firmware via a mechanism other than a PC connected to the USB port. An on-board firmware loader isn't robust like the teensy loader - so I see it as an added, non-competitive feature that increases teensy sales.

Blackketter has a good point - adding a serial (or I2C) connection option to the teensy boot loader process would solve the need and be robust. This could be done with a boot loader software only upgrade (no new wires).

Another option might be the new ESP32-S2 (with USB OTG (but no bluetooth)). It could probably be programmed to update teensy firmware via the existing USB mechanism.
 
I'm absolutely in favor of Paul's business model and want to see it continue. But there is a market need for the ability to put a teensy in a sealed, in-the-field device and then update the firmware via a mechanism other than a PC connected to the USB port. An on-board firmware loader isn't robust like the teensy loader - so I see it as an added, non-competitive feature that increases teensy sales.

Blackketter has a good point - adding a serial (or I2C) connection option to the teensy boot loader process would solve the need and be robust. This could be done with a boot loader software only upgrade (no new wires).

Another option might be the new ESP32-S2 (with USB OTG (but no bluetooth)). It could probably be programmed to update teensy firmware via the existing USB mechanism.

I suspect the boot loader CPU does not have access to the SPI, serial, or I2C pins.

For hackers with a single board, using a Pi Zero W (or Pi Zero if you don't need wifi) has been talked about in the past. It is a smallish form factor, the loader has been ported to the Pi, and the few places that sell it sell it cheap ($10 for the W, $5 for the non-W -- plus a few $ for the micro SD card and soldering the connections to the Teensy). However, the problem is the Pi Zero W/no-W are typically only available in quantity one, and at times have not been available. The reason is at that price point, it is not economical for the vendors to sell it. I have to imagine it may even cost more than the $5/$10 base price, but the Raspberry Pi foundation produces it specifically to further its mission of encouraging people to program (presumably the higher priced Pi's fund keeping the Zero in production).

So for a commercial enterprise, it isn't a viable option. The larger Pi's are available, but they are more expensive and consume more power.
 
> I suspect the boot loader CPU does not have access to the SPI, serial, or I2C pins.

The same could be said of the USB pins - but it doesn't matter. Most of the boot process code runs on the main MCU, which has access to all of the needed pins.
 
I have considered adding this sort of feature. It may happen. But I can tell you 2 things with certainty.

1: This won't happen within the next 6 months. So much needs to be done with Teensy 4.0 libs and special features. Better documentation is also urgently needed.

2: Any bootloader update, even for something trivial, involves tremendous risk. Mistakes in the bootloader can permanently brick your Teensy. Often with normal libs I do things very quickly and publish beta code after just a couple quick tests on my workbench, usually only testing with my Linux desktop machine. But the process of coding and testing is so much slower with the bootloader, because of the danger of bricking boards.

So, with those 2 points in mind, let's talk about what specific hardware & protocol ought to be supported... (accepting this is all hypothetical at this point and may be many months or year until it happens, *if* it ever happens at all)

Also, what is the possible backwards compatibility risk to everyone who has used Teensy where all the pins are tri-state during uploading? If this feature is implemented, pins 0 and 1 would become active during uploading. Especially pin 1 (TX1) would be driven high.
 
> Especially pin 1 (TX1) would be driven high

Best if the loader doesn't activate the TX pin until it receives some signal that serial loading is desired. Perhaps a certain byte received on the RX pin?

I don't have much concern about protocol. The simplistic one I used works and catches most errors.
 
One thought that I just had is perhaps an IDE option that would build an executable image that includes the Teensy download module and the current ELF executable encoded in some fashion. This executable should depend on as few host libraries as possible. When the executable is run, it looks for a Teensy on USB, and does the download sequence. This way you could provide a way similar to the way firmware is often installed by running a stand alone binary.

Extra credit if you can add versions for each of the Teensy versions, and/or supporting building binaries to run on other host OSes.

You can even use it to go back to a specific version to test things out. And this way you don't have to worry about changes to the infrastructure (new compiler, new teensydunio, incompatible libraries).

Something like this would not necessarily have to be implemented by Paul (whose to-do list is already pretty long).

Sure there are plenty of cases it doesn't cover. Some people that need to be able to do this remotely without any assistance from the user, particularly if it could be done in a wireless fashion. And particularly on the Linux side of things, there are so many distros that it can be hard to make sure you have a universal binary. But it would be a lot easier to have one binary that does the download.

Another thought is having the ability to read binaries from Teensys with an attached micro-SD card (i.e. 3.5/3.6 normally, 4.0 that has one of the breakout boards installed, anything with the audio shield) and load them onto the Teensy. Again, you might want an IDE option to copy the ELF file to a specific location.
 
I have considered adding this sort of feature. It may happen. But I can tell you 2 things with certainty.

1: This won't happen within the next 6 months. So much needs to be done with Teensy 4.0 libs and special features. Better documentation is also urgently needed.

2: Any bootloader update, even for something trivial, involves tremendous risk. Mistakes in the bootloader can permanently brick your Teensy. Often with normal libs I do things very quickly and publish beta code after just a couple quick tests on my workbench, usually only testing with my Linux desktop machine. But the process of coding and testing is so much slower with the bootloader, because of the danger of bricking boards.

So, with those 2 points in mind, let's talk about what specific hardware & protocol ought to be supported... (accepting this is all hypothetical at this point and may be many months or year until it happens, *if* it ever happens at all)

Also, what is the possible backwards compatibility risk to everyone who has used Teensy where all the pins are tri-state during uploading? If this feature is implemented, pins 0 and 1 would become active during uploading. Especially pin 1 (TX1) would be driven high.

Thanks, Paul, I realize that this is a long-term project and am just glad that you are thinking about it for the future. And totally agree about making sure it's rock solid to avoid dead Teensies.

What I was trying to suggest was a new pair of pins that are directly connected to the bootloader chip and not to any existing pins, so I wouldn't expect this to affect the existing trii-state behavior.

At a minimum I would hope for emulation of the existing functions provided over USB by the bootloader: erase and write flash, reboot. Factory reset (to blink) would make sense.

The ROM UART bootloader mode in the ESP8266 and ESP32 https://github.com/espressif/esptool/wiki/Serial-Protocol might be a source of inspiration, it adds some additional features like reading and verifying flash, read/write to RAM, compressed flash writing, and jump to a specific memory location. (I'm not sure how much of this is possible.)
 
Just for my curiosity. What would be the advantage of connecting the ESP to those UART interface? Why not simply connecting it to the standard Teensy USB port and do the programming over that? (AFAIK there are USB libs for a standard ESP and the ESP32-s2 seems to have a USB port on board)
The programming procedure is well documented and simple to implement. There are a few threads here with corresponding demo code. Paul also has a Repo on GitHub showing how to do that.

Would be really interested in a use case for the serial programming interface
 
Just for my curiosity. What would be the advantage of connecting the ESP to those UART interface? Why not simply connecting it to the standard Teensy USB port and do the programming over that? (AFAIK there are USB libs for a standard ESP and the ESP32-s2 seems to have a USB port on board)
The programming procedure is well documented and simple to implement. There are a few threads here with corresponding demo code. Paul also has a Repo on GitHub showing how to do that.

Would be really interested in a use case for the serial programming interface

The ESP32-S2 looks really interesting and could be used as you described.

Indeed, if the ESP32-S2 has a robust USB host implementation, it could give the Teensy 3.6 and 4.0 a good bit of competition for some applications.

There are a few issues I can think of:

1. The ESP32-S2 hasn't been released yet and it's unclear to me if its USB OTG port will be able to support host mode with the Teensy upgrade protocol.

2. Depending on the board design, the USB-to-USB connection may not be feasible (i.e. Paul has explained elsewhere that the T4 USB connection can't be broken out to pins and is only available via the USB connector).

3. In some systems the USB device port on the Teensy may be needed for other applications, where the Teensy is talking to another USB host that can't do the upgrade in the field.
 
My use case was firmware updates over a specific bluetooth module. USB wasn't an option.
 
So, with those 2 points in mind, let's talk about what specific hardware & protocol ought to be supported... (accepting this is all hypothetical at this point and may be many months or year until it happens, *if* it ever happens at all)

I have a 64x64 LED panel on the garden fence towards the street as a lit house number with a 5A buck converter, a Teensy, Smartmatrix, and some code of mine. I have 65m of 6x2x0.8mm sealed telephone wire routed from the house to that place, of which I use 2x2 for 19.5V. I've successfully used CAN on 1x2 of those cables up to 110m in other places in the garden for irrigation valve control purposes with Arduino Nanos and CAN MCP2515/TJA1050 modules, including a CAN boot loader of mine that allows to address individual devices on the bus and that can even replace itself. It would be nice to be able to upload new software also onto the Teensy over the 65m cable via CAN. A serial boot protocol on the Teensy would probably do, then I could design a companion controller handling the CAN<->UART business. My 2c.

Kind regards, Sebastian
 
I have accomplished a great OTA with my teensy based project . I needed a way to manage several t3.2 boards. Each t3.2 has a custom PCB edge connector that sockets into a pcb 20 pin connector(usb, power, program, led status etc) . To accomplish OTA I designed a custom usb 2.0 backplane that allows me to socket the boards. Each usb backplane also has USB port power control and bootloader program control so If need to power cycle the teensy or invoke the physical program pin I can through software. The power and program pins are managed from a simple microcontroller that is In tandem with the Linux sbc (like the raspberry pi) the Linux platform Is a LAMP stack servicing firmware updates over usb (using tycommander) and php serial to tell each t3.2 the commands and configuration settings. Yes it’s a bit too much for a simple approach but in a multi teensy environment it makes managing firmware and control a breeze
 
Last edited:
With influx of very inexpensive Linux based boards it should give some here the ability to manage the firmware via web engine and USB port to the teensy . Tapping into a power control method and program button also allows reboot and firmware recovery possible. At a service level for me its easier to fix Linux issues (replace sd card) and recover and upload good firmware through program button option. This approach allows pretty reliable solution with the ability to recover the MCU.

One frustrating issue with a system that relies OTA or network without a reliable method of recovery is that it can be bricked. Granted it’s not common in well designed systems. Interestingly I do happen to have a pile of polycom conference phones that are worthless. The configuration / firmware is bricked and as of yet no way to recover them. At $500 a phone too bad they didn’t have a better way to recover.
 
Last edited:
What is the current status on this, does Teensy 4.0 have true HW support to upload FW over HW serial?
 
Back
Top