Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 15 of 15

Thread: A crazy idea for Teensy firmware updating

  1. #1
    Senior Member
    Join Date
    May 2015
    Location
    San Francisco
    Posts
    197

    A crazy idea for Teensy firmware updating

    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?

  2. #2
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    306
    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.

  3. #3
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,398
    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.

  4. #4
    Senior Member
    Join Date
    May 2015
    Location
    San Francisco
    Posts
    197
    Quote Originally Posted by jonr View Post
    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.

    Quote Originally Posted by jonr View Post
    It would be nice if someone implemented gdbstub for the teensy.
    Agreed!

  5. #5
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,136
    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....

  6. #6
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    306
    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.

  7. #7
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,377
    Quote Originally Posted by jonr View Post
    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.

  8. #8
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    306
    > 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.

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,835
    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.

  10. #10
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    306
    > 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.

  11. #11
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,377
    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.

  12. #12
    Senior Member
    Join Date
    May 2015
    Location
    San Francisco
    Posts
    197
    Quote Originally Posted by PaulStoffregen View Post
    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...erial-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.)

  13. #13
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    578
    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

  14. #14
    Senior Member
    Join Date
    May 2015
    Location
    San Francisco
    Posts
    197
    Quote Originally Posted by luni View Post
    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.

  15. #15
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    306
    My use case was firmware updates over a specific bluetooth module. USB wasn't an option.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •