possible new bootloader features

WMXZ

Well-known member
First of all, I like the Teensy dedicated bootloader architecture.
However, after a year or so working with T3.1 and with the availability of TLC, I start missing some features that could be combined in some sort of

expert mode:
A simple escape command send while the bootloader has control would allow a finite number of interactions with the bootloader

[1) Type of device (3.0,3.1,LC), edit: not needed, is detected by TeensyLoader]
2) retrieval of name and creation date of the loaded program (needs this info stored somewhere)
3) download new program (obvious)
4) retrieval of name and creation date of a small (128-512 byte) parameter file stored at fixed location (content under user responsibility)
5) download of parameter file
6) exit with/without reboot

Default behavior of bootloader as is

to enter expert mode, one would need a dedicated program (simple terminal based program with a 6-item menu is more than sufficient)
 
Last edited:
Knowing programmatically the Teensy type, would allow new versions of TeensyLoaders to send the right program to the different MCU without having me to manually switch port and device
Reading the HID report descriptor from the bootloader will tell you the model. Just read the primary usage page key from the descriptor (not sure about the first three, don't have any of them):
- Teensy++ 1.0 = 0x1A
- Teensy 2.0 = 0x1B
- Teensy++ 2.0 = 0x1C
- Teensy 3.0 = 0x1D
- Teensy 3.1 = 0x1E
- Teensy LC = 0x20 (apparently, don't have one)
 
Reading the HID report descriptor from the bootloader will tell you the model. Just read the primary usage page key from the descriptor (not sure about the first three, don't have any of them):
- Teensy++ 1.0 = 0x1A
- Teensy 2.0 = 0x1B
- Teensy++ 2.0 = 0x1C
- Teensy 3.0 = 0x1D
- Teensy 3.1 = 0x1E
- Teensy LC = 0x20 (apparently, don't have one)

OK, one item less.
Found it and this will help with my mixed Teensy software development.
 
Please understand the incredible risk associated with adding features and complexity in the bootloader.

I am going to add more features. Other than the pin 33 fix, I can't discuss details at this time. But I will say the available code space is also a limiting factor, which also creates a strong disincentive for me to add more features.

I'm not saying absolutely no. Maybe some simple way to read back something could be possible in a future version. I'll keep it in mind. But don't expect to see this sort of thing anytime soon. The combination of risk and limited space creates a pretty high barrier to packing more functionality into the bootloader!
 
Please understand the incredible risk associated with adding features and complexity in the bootloader.

I am going to add more features. Other than the pin 33 fix, I can't discuss details at this time. But I will say the available code space is also a limiting factor, which also creates a strong disincentive for me to add more features.

I'm not saying absolutely no. Maybe some simple way to read back something could be possible in a future version. I'll keep it in mind. But don't expect to see this sort of thing anytime soon. The combination of risk and limited space creates a pretty high barrier to packing more functionality into the bootloader!

I completely understand and at least for my usage it would be a great help, if the bootloader store filename and creation time in a safe place to read back at any time.
 
I completely understand and at least for my usage it would be a great help, if the bootloader store filename and creation time in a safe place to read back at any time.

Something for the new bootloader chip?
 
I'm pretty sure this is a perfect example of a feature that's requested in the form of a "simple" addition... but the actual intention, the actual goals it tries to achieve involve much, much more work to deliver in a satisfactory way.

This is how "feature creep" happens, by saying "yes" to something simple. Then after the software stores pretty much the same as you could get with __FILE__, and has a way to read it back, then you're faced with the problem that file is missing, or has long since been overwritten with numerous revisions and no longer matches the actual binary code inside Teensy.

Even though the feature was requested as just reading a filename.... to be useful, there needs to be true integration with the Arduino IDE (or other platforms?) to actually archive the complete source code at the moment it was uploaded to Teensy. Suddenly, not such a simple feature....

Or maybe the purpose is something else? I'm guessing a bit here.
 
I'm pretty sure this is a perfect example of a feature that's requested in the form of a "simple" addition... but the actual intention, the actual goals it tries to achieve involve much, much more work to deliver in a satisfactory way.

This is how "feature creep" happens, by saying "yes" to something simple. Then after the software stores pretty much the same as you could get with __FILE__, and has a way to read it back, then you're faced with the problem that file is missing, or has long since been overwritten with numerous revisions and no longer matches the actual binary code inside Teensy.

Even though the feature was requested as just reading a filename.... to be useful, there needs to be true integration with the Arduino IDE (or other platforms?) to actually archive the complete source code at the moment it was uploaded to Teensy. Suddenly, not such a simple feature....

Or maybe the purpose is something else? I'm guessing a bit here.

Let me explain the purpose of my suggestion on access to filename of the loaded program via the bootloader chip.

Let us assume I have a data acquisition system that has the same hardware (audio card) but is running different SW (one featuring LP filter, the other a HP filter). The SW may therefore have different names ("acq_lp.hex", "acq_hp.hex", loaded at 17-sep-2015, name and date could be merged).
There are various deployments at different times of hardware that look similar.

Once loaded onto Teensy, I lost control about which SW is loaded (apart from my notes), i.e. there is no way to know from the host which SW is loaded onto Teensy.

Imagine further that you as developer of the acquisition system get a call from a remote island, saying that the control led of one the deployed system is not anymore blinking, the first question I would ask is, which software version is running, before trying to find the error and send a new code (even if my spreadsheet is updated, double checking is essential).

What I need (and have done on other systems) is the capability by SW (via a host program) to interrogate the HW and to read back which SW was loaded and when.

It is not the question that the loaded SW knows its creation time, but to know from outside teensy which SW was loaded last, without using a custom bootloader.

A custom bootloader would accept the command "put filename" and write the info to dedicated memory (first 40 characters) and would allow command "get filename" to read this dedicated memory. My suggestion was that such functionality could be added to bootloader chip.

I say filename, because that is where I was coming from, but any user information would be fine. If this memory space is extended somewhat, I could imagine to use the as parameter space that allows the program to run in different modes.

Concerning Arduino, opening the feature space does not break compatibility but could allow users that only use cli (like myself) to get more out of the HW.

I will not pull the string further suggesting the bootloader chip to run a small menu, allowing to set RTC, download SW, setting some environmental data as I have on other systems.

OK,
I only brought this up again, because you said the new chip is easier to program, and I see different possibilities in using such a feature.

And, of course, I know how to bypass the bootloader chip, but that is not the issue here.
 
I do not understand why these are tasks for the bootloader and not for the mk20dx256, can you help me ?
The mk20 can hold all these infos (and much more) and to send these data over usb (hid/serial or whatever) or show them on a display takes only few lines of code.
 
What I need (and have done on other systems) is the capability by SW (via a host program) to interrogate the HW and to read back which SW was loaded and when.

The real question is whether this functionality should be implemented inside the bootloader, or as extra code in your application.

For example, if you get that call from the remote island and you need to determine which code they are running... if the feature is in the bootloader, they have to go press the button on Teensy. Or run teensy_reboot.exe. Either way stops your code from running, which disrupts whatever important service it's providing (obviously important enough that you're providing telephone support to remote locations). Not only does your application stop performing its task, but unskilled people are placing the Teensy into programming mode without certainty they've selected the right board. If they make a human error, like having auto mode enabled, things could get ugly very quickly.

If you build identification into your application, the benefits are obvious. Interrogating the file name doesn't disrupt your code. It doesn't risk accidentally overwriting it. The only downside is you have to do a little more programming in your application.

Maybe I've misunderstood your needs? From everything you've said, I can't understand why this should be in the bootloader, instead of built into your own application.

Well, other than PJRC does all the dev work to make it happen. :) But even in that case, wouldn't an example that you can copy to your application be better than having it built into the bootloader?

I should also mention the VideoDisplay example in OctoWS2811 has this sort of identification functionality. It's allows each Teensy to tell the PC which portion of a large LED project it actually is. On the PC side, assigning each COM port or serial device is tricky, and problematic if your PC changes or you move to another machine where the port names differ. Having each Teensy report its configuration and physical location allows the software to automatically send each one the proper portion of the image. The VideoDisplay code is in the OctoWS2811 examples, and the PC-side Processing code is in a folderer within that example sketch.

I only brought this up again, because you said the new chip is easier to program

The KL02 is indeed much better than the Mini54. But all bootloader dev involves substantial risk and requires much more testing, regardless of how easy the hardware is to work with. Space is also still quite limited, and this feature involves expanding the USB communication protocol (currently no actual data flows from Teensy to PC, other than status info)... and I have some really awesome but incredibly difficult ideas for the distant future, which will need the space.
 
I do not understand why these are tasks for the bootloader and not for the mk20dx256, can you help me ?
The mk20 can hold all these infos (and much more) and to send these data over usb (hid/serial or whatever) or show them on a display takes only view lines of code.

This requires the program on the mk20 to run (not continuously crashing) and all applications must have a fixed frontend menu
It is also hard to start automatically a program with frontend menu.

re display on Teensy: assume Teensy is in a watertight pressure housing with only an USB connection, a display will be hard to see, also Teensy must run. KL02 runs always on reboot.

IMO, a dedicated bootloader manages the SW on K20 and part of the management is the provision to report what has been done.
BUT ....
 
I do not understand why these are tasks for the bootloader and not for the mk20dx256

That's where I got stuck too. If you have USB connect to the device and it is functioning ...

Maybe I'll remember to write this in the 'right' thread - but if the T3++ has outputs that don't reach pins - an RGB led wired would be handy for diagnostic info. - 5 cents with resistors?
 
The KL02 is indeed much better than the Mini54. But all bootloader dev involves substantial risk and requires much more testing, regardless of how easy the hardware is to work with. Space is also still quite limited, and this feature involves expanding the USB communication protocol (currently no actual data flows from Teensy to PC, other than status info)... and I have some really awesome but incredibly difficult ideas for the distant future, which will need the space.

I'm not insisting and look forward to new developments
 
Issue as I see it is that if the device is running well enough to communicate over USB, then a simple Terminal session will allow a average users fairly quick access to the relevant data (i.e. plug in a USB cable and watch what comes). IF the device is semi-bricked, then I fail to see how having access to bootloader data has any benefit unless you DIY a board that can talk to the bootloader independently of the MCU (since the latter controls all USB traffic).

Seems to me that a better solution would be to have a watchdog CPU that operates independently of the main CPU and which can log data, reset the main MCU as needed, etc. This could be as simple as a LC MCU listening in on the USB channel or using one of the serial ports, while logging diagnostic data to a SD drive. The cost would be moderate ($3 for the MCU, $5 for the BOP, $5 for the card and holder, and $8 for the second bootloader if you keep it all on one board). A $20 solution for high-reliability applications seems like money well spent.
 
KL02 runs always on reboot.

Oh, I think I see what you're saying. Perhaps you're very familiar with how Arduino's bootloaders work, and you're (mis)applying that understanding to Teensy?

When you power up a Teensy, the Mini54 or KL02 does NOT take control of the USB. The MK20 chip boots up without interference from the bootloader. This is by design. The Teensy bootloader does *not* interfere with the MK20 chip startup. The idea is for your program to start up and run as if you'd directly programmed onto the MK20 using ISP (a.k.a "ezport" in Freescale's lingo) without any bootloader present.

Arduino's bootloaders are very invasive to the startup process. The chip starts up running the bootloader code. It waits for communication from the PC, and only after a timeout does it run your application.

Teensy startup works as if there's no bootloader at all. The idea is to give you as direct, unfettered access to the chip as possible, and the chip's native/fast startup.
 
Oh, I think I see what you're saying. Perhaps you're very familiar with how Arduino's bootloaders work, and you're (mis)applying that understanding to Teensy?

When you power up a Teensy, the Mini54 or KL02 does NOT take control of the USB. The MK20 chip boots up without interference from the bootloader. This is by design. The Teensy bootloader does *not* interfere with the MK20 chip startup. The idea is for your program to start up and run as if you'd directly programmed onto the MK20 using ISP (a.k.a "ezport" in Freescale's lingo) without any bootloader present.

Arduino's bootloaders are very invasive to the startup process. The chip starts up running the bootloader code. It waits for communication from the PC, and only after a timeout does it run your application.

Teensy startup works as if there's no bootloader at all. The idea is to give you as direct, unfettered access to the chip as possible, and the chip's native/fast startup.

For the sake of clarification, I do not know Arduino, I was referring to custom made TI 5509 DSP system (which I did not build but used to program), but that does not matter.
Concerning Teensy, my understanding was, that on pressing reboot button, the MK20 reboots without running the installed program (maybe it is put on hold by KL02, some logic or similar) It is then the KL02, which (via MK20 USB) receives the data and stores them onto flash. Of course it could be hat KL02 copies the proper bootloader into MK20 RAM that receives the data and stores them on flash. Maybe I'm wrong, but assuming you cannot or prefer not to go into technical details of how the Teensy boot process really works. In either way, I only suggested to consider an extension of the boot protocol to allow limited amount of operation( storing and reading some additional information). But I accept that this is not very high on the list of Teensy users and may be too risky.
 
Oh, it does indeed set C_DEBUGEN, just not anything that halts or delays the program from running.

Teensy LC and 3.2 do clear C_DEBUGEN when the KL02 detects a low power mode and puts itself to sleep. If you want C_DEBUGEN cleared, you must enter a sleep mode for about 0.1 second or more.
 
Back
Top