Bootloader Chip For Teensy 4.0

Well, there need to be a real Arduino approach.
That is, reinventing the wheel and making it open source. An Arduino bootloader and programming tool, preferred by using existent options. Could well be based on NXP's resources.
This would then open the path for the open source community while the self-blocked Teensy ecosystem develops more and more towards a closed system dependent on a single person's well being and mood.

But then it will be 1170.
Same effort, more result.

I guess this will make Teensy 5 almost obsolete....
 
Well, there need to be a real Arduino approach.
That is, reinventing the wheel and making it open source. An Arduino bootloader and programming tool, preferred by using existent options. Could well be based on NXP's resources.
This would then open the path for the open source community while the self-blocked Teensy ecosystem develops more and more towards a closed system dependent on a single person's well being and mood.

But then it will be 1170.
Same effort, more result.

I guess this will make Teensy 5 almost obsolete....


The "Arduino approach" involves having an ancient editor they call "IDE", ancient hardware, hardly any hardware-related software that comes near the one PJRC has and no almost no step forward since 10 Years. A few ministeps, okay.

Well, feel free to use other Arduino Boards.

I don't need that bootloader chip to write my software. There is no reason for a bootloader chip if you want to write software and do projects. A bit more debugging-possibilities would be good - but it works without. As you see. As you use it - You're still here... :)

A bootloader-less system is useful only for china-companies who then make and sell the boards. Happily using the already developed software.

Btw, they'll never produce a 1170 with that software-support.
Too much effort for them, if the can't rely on existing work.

If it was that easy, where is your china 1062? Or "Arduino" i.mx.rt?

Nothing there? oops :)
Or, is there something better? If so - why are you still here?


I remember - did'nt you want to extend the Audio-Library? 48Khz, float, sample-rates converters and so on? How is your progress?
 
Last edited:
Not know. I have nothing to do with China, except for some china cups and plates, or the occasional Kong Bao from the takeaway.....

Arduino is Italian.

What the Chinese copy is leftovers, cheapo old stuff nobody really wants. So where is the danger? One who only wants to spend a few HK$ to a copycat has reasons to do so and would anyway not spend higher amounts of real money for a real and serious product. Maybe even these customers just need that learning experience and if able to do so will turn to the real stuff.

I think the USP is quality.
With this are all options open, but not to the copycat, who are just unable. But unfortunately also this chance has not been taken by PJRC, considering some T4.0 and T4.1 had to be reworked because the BGA has not been correctly soldered. Unfortunately I was not aware of that batchcode near the connector, otherwise would have recorded that before leaving products to pals.

The success of PJRC Teensy is mainly based on the input from the open-source community, but there comes not even the slightest cooperation from PJRC side.

I leave it to the discussion, if this is good behaviour.

Did anybody notice I do not release anything to this? It has a reason. And see what comes up next.

BTW: Arduino is cooperative with a lot of other IDE. So no point in that.
 
Yup, but a lot of (or all?) Italian Arduino boards have cheap china clones.

By the way:

After the 4.1 card is completed, I'm going to switch focus for a while, to get the 4.x bootloader chips released and if not add support for encrypted firmware, at least make sure we have a viable path to supporting it (before so many chips get soldered to people's custom boards).

That's going to mean a pause in website updates. So many important points have been raised on this thread. We do need a lot more documentation. I will return to website updates, but please understand I'm going to switch away from website updates for a while, since so many people are waiting for those chips to make custom boards.
 
And regarding Audio: May I remind you of Paul's statements about enhancing it or incorporating additions to the Teensyduino release?
I do not collect them around the forum, too cumbersome to find their position.

There is NO cooperation. An existing F32 OpenAudio for Teensy is there already.

And there are options in hardware for interfacing to USB, I2S and S/PDIF, leaving the Teensy the job as a number wigller. Or any other MCU.
 
Just a quick update. I am hoping to begin a "soft release" of the T4 bootloader chips next week, and a full release later in February.

A "soft release" means we are going to limit the per-person quantity to about 5-10 chips, and we will request that you communicate directly with us about your experience using the chips. There are 2 main reasons for a this "soft" release.

1: Initially we'll have very little bootloader specific documentation and PCB design guidance, only the schematics and files published for Teensy 4.0 & 4.1.

2: Robin & I are working on logistical changes in how we will program these chips, mainly focusing on removing all manual human steps between the programming and printing of the label we put onto the packaging material. We're also trying to limit possibility for human error between your clicks on the website and which programmer hardware we use. Today we sell only 2 chips, and they are physically very different so it's easy to tell them apart. Once we add the T4 bootloader, we'll be shipping the same physical MKL02 chip (no MKL04 option for T4) but with different firmware. This process stuff may be overly paranoid, but I want to be very certain we can't accidentally send T3 bootloader chips when T4 are ordered, and vise versa.

The soft release is meant to make prototype quantities of these chips available for your project, while we work on documentation and redesigning our material handling process. When we later move to full release, you'll be able to buy any quantity and as now the policy will be "no questions asked" about your custom PCB design (unless of course you want help troubleshooting... that's always done on this forum).


Here are some random technical details...

The fuse initialization is working, including the ethernet mac address / USB serial number. This has been the main technical obstacle. I can confirm it is solved.

Initialization of the flash isn't working yet, but I plan to have that by next week.

The 15 second restore program has been updated to automatically detect which flash chip your board uses (rather than distinct versions of the restore process, as we use now on Teensy 4.0 vs 4.1).

The bootloader chip will *not* lock your IMXRT fuses or flash chip. If you want to burn additional fuses, you will be able to do so. Certain fuses settings can permanently brick your board. We'll publish a program you can run to lock your fuse settings & flash restore to prevent any "bricking" possibility, as we have on Teensy 4.0 & 4.1 (but then you forever are locked out of turning on security or other fuse settings which affect startup).

Initially the booloader will not support encrypted firmware or HAB authentication, but some provisions have been included so we can (hopefully) add this support with a software update in the future.

A simple hardware diagnostic using patterns of red LED blinks is also planned, but not yet implemented. This is the last major piece to go into the bootloader before a soft release. If your hardware works, then you'll never use this feature. But if something is wrong, rather than "dead board", you'll get a series of LED blinks to tell you what the bootloader thinks is wrong with your PCB. The T4 hardware is significantly more complex than T3, and the T4 bootloader has some speed optimizations which make its behavior more complicated than T3 (eg, Reset isn't held low while Program is low), so this diagnostic can hopefully help when things don't go as planned.


I know the wait has been very long & frustrating. We're almost there. Please, if you want to chat, discuss here, but DO NOT send a private email. When we're ready for the soft release to begin (very likely sometime next week) I will post about it here. So please subscribe to this thread to get notified when chips are ready.
 
Last edited:
> A simple hardware diagnostic using patterns of red LED blinks is also planned

Nice! - black boxes are hard to debug. Would be very helpful to distinguish between "loader can't talk to MCU", "crystal isn't working" and "MCU can't talk via USB to the PC" (I've experienced all 3). Possibly there could be a slow boot option to provide time to blink out each stage (or an oscilloscope could be used with very fast blinks).
 
Possibly there could be a slow boot option to provide time to blink out each stage

It's not going to do anything so complex. And even if it did, the nature of most failures is that you can't attempt the next stage anyway. If communication with the IMXRT fails, there's no way to check whether the crystal is oscillating or do anything else. If you can talk but the crystal doesn't work, there's no way to turn on the PLLs and attempt USB. The flash chip is one part that might be possible to give more info when other parts also fail, but there too, if the flash isn't accessible you don't have the info needed for USB descriptors (Teensy Loader needs to know which flash chip), so flash chip checking is done before USB is attempted.

So the nature of the diagnostic blinks will be to report exactly 1 failure. Whatever caused it to stop will be reported. Once you fix that problem, if something else is also not right, you'll get a new blink pattern when that other problem is encountered.

But not every hardware issue can be detected by the bootloader. Especially USB wiring errors like swapping D+ / D- aren't possible (at least as far as I know) for code to diagnose. My hope is limited diagnostic blinking will make troubleshooting easier than no info, but I can't do everything.
 
You can hide a software-serial into the blink.. if fast enough it wouldn't be visible and look like "LED ON" but with a optical link you could see debug messages ;)
Ok, just a dumb idea, ignore it.
 
Another quick update - all the new code is in. On a virgin board, the fuses IMXRT fuses are set the first time the MKL02 talks to it. The initialization delivers a unique ethernet mac address as well. The flash chip gets the 15 sec restore image written to it the first time you go into bootloader mode. Thereafter, the 15 sec restore works and the board comes up as RawHID. The LED blink diagnostic is working. It blinks between 2 to 13 times to indicate various failures (2, 3, 4 blinks for the common hardware issues). Last night Robin & I did some subjective testing with the blinking speed, so it's quick enough to not waste your time & get boring on the long sequences, but slow enough to be easy to count the blinks.

So far I've been testing on the Teensy 4.1 hardware and using tweezers to short places on the PCB and chunks of code to simulate hardware problems. Later today I'm going to start testing on 4.0 hardware and intentionally damage some boards to make sure the diagnostic LED blink really does detect those cases. If all goes well, we'll hopefully be programming chips tomorrow and soldering them to boards for a final test.
 
Another quick update - all the new code is in. On a virgin board, the fuses IMXRT fuses are set the first time the MKL02 talks to it. The initialization delivers a unique ethernet mac address as well. The flash chip gets the 15 sec restore image written to it the first time you go into bootloader mode. Thereafter, the 15 sec restore works and the board comes up as RawHID. The LED blink diagnostic is working. It blinks between 2 to 13 times to indicate various failures (2, 3, 4 blinks for the common hardware issues). Last night Robin & I did some subjective testing with the blinking speed, so it's quick enough to not waste your time & get boring on the long sequences, but slow enough to be easy to count the blinks.

So far I've been testing on the Teensy 4.1 hardware and using tweezers to short places on the PCB and chunks of code to simulate hardware problems. Later today I'm going to start testing on 4.0 hardware and intentionally damage some boards to make sure the diagnostic LED blink really does detect those cases. If all goes well, we'll hopefully be programming chips tomorrow and soldering them to boards for a final test.

Ditto to what @KurtE said and congratulations - sounds like the finish line is in site!
 
Yet another update... doing more testing. This morning I found (and fixed) a timing issue with initializing the flash chip's non-volatile status2 register. This is another place where the Teensy test fixture initializes the hardware. The bootloader has code to also initialize it (leftover from the earliest days of developing Teensy 4.0), but of course that code has never actually been run on any production Teensy since the flash chip is always configured properly by the text fixture before the bootloader can ever run. But on a custom PCB the bootloader will be responsible for all this stuff that's done by the Teensy test fixture. That never-used initialization code was working with some flash chips (the 3 boards/chips I tested yesterday), but failing on others which need longer time to write to that register. I've rewritten it to properly poll the flash chip's busy status rather than relying on fixed delay. I also replaced 2 other places with busy-loop delays with timer-based delay, and generally went though all the code looking for other possible timing issues.

I do feel like we're getting very close.
 
Great news Paul - big difference supporting a known system with (fixed) BOM for in house builds - versus supporting a generic range of items like FLASH chips.
 
Yet another update - programmed 3 chips today and soldered them to virgin boards. The bootloader comes up and works with Teensy Loader, but still some issues remain with booting up in certain cases. Still more work to be done before we can release these chips.
 
Still yet another update...

For the last couple days I've been searching for the cause of a strange startup bug, going over everything in the bootloader. But it turned out to not be a booloader problem at all. Looks like I added a bug in the LED blink restore image, but that bug was only manifesting on a cold boot. From a warm boot it the LED blink work work perfectly. Other programs from Arduino would boot either warm or cold.

Yeah, kind of embarrassing that problem turned out to be just the LED blink program. But it's not the ordinary LED blink compiled by the Arduino IDE. It's a trimmed down copy with fits in the top 4K of flash. It implements USB RawHID, but only just enough to hear the auto-reboot request from Arduino. I had to cut a lot of corners to make it fit...

When we test Teensy 4.0 and 4.1, this LED blink program is written into the top 4K by the test fixture. Teensy 4.0 and 4.1 get slightly different copies, where the BCD version bytes in the USB descriptors differ, so the info which shows up in Arduino's Tools > Ports menu correctly shows which Teensy model you have. On Teensy 4.0 and 4.1 this is easy, since each test fixture has the correct version of the LED blink.

Now the tiny LED blink needs to read the flash chip ID to know whether to tell Arduino to show 4.0 or 4.1. That new code in the LED blink program seemed to be working fine. But it turned out I had only tested from a warm boot.

Then when I started testing by actually soldering a just-programmed chip onto virgin boards, I was cold booting. The bootloader came up and seemed to work in every way, and normal programs would work fine, but the 15 sec restore LED blink would sometimes work, sometimes fail to start up.

So I've lost the last couple days getting to the bottom of this strange startup issue, which turned out to be only the LED blink program not always managing to read the flash ID so it can give the correct USB identification!!
 
Wow - that is tedious grief to work through! Such subtle issues WE never see ... even on Beta test units you've gotten over all those issues ... well except the 'white wire' one which was easy to work around until resolved.

That reminds me of a question a prior post gave: Pin and feature layout define it as 4.0 or 4.1.
question?:: can the FLASH be user selected among a selection of chips : 2,4,8,16,32,64 MB at will, or must they be the expected size matching the production model 2MB or 8MB?
 
Starting another round of (hopefully final) late night testing.

For a visual idea of how it's going... here's an untested virgin Teensy 4.1 with its MKL02 chip removed and a freshly programmed MKL02 about to be soldered.

chip.jpg

The funny background color is a pink anti-static bag which I use to catch the liquid solder flux from spilling on my workbench. The colors are a bit off because this photo was taken with the board still under my microscope's LED ring light which doesn't agree with the camera's white balance, and this pushes the limits of my old camera's semi-macro capability using only the kit lens. The weird circle reflections on the solder joints of pins 23 & 22 are the microscope ring light.

I just finished soldering and washing this board. It's drying in the oven now, while I write this message.


even on Beta test units you've gotten over all those issues ... well except the 'white wire' one which was easy to work around until resolved.

Yup, on those beta boards I manually did the many steps the test fixture does.


can the FLASH be user selected among a selection of chips : 2,4,8,16,32,64 MB at will, or must they be the expected size matching the production model 2MB or 8MB?

Only 3 flash chips will be supported, W25Q16JV**IM, W25Q64JV**IM, and W25Q128JV**IM. This and so many other design issues still need to be documented. These IMXRT chips have a much more complicated startup process than simpler microcontrollers.
 
Starting another round of (hopefully final) late night testing.

For a visual idea of how it's going... here's an untested virgin Teensy 4.1 with its MKL02 chip removed and a freshly programmed MKL02 about to be soldered.

...

The funny background color is a pink anti-static bag which I use to catch the liquid solder flux from spilling on my workbench. The colors are a bit off because this photo was taken with the board still under my microscope's LED ring light which doesn't agree with the camera's white balance, and this pushes the limits of my old camera's semi-macro capability using only the kit lens. The weird circle reflections on the solder joints of pins 23 & 22 are the microscope ring light.

I just finished soldering and washing this board. It's drying in the oven now, while I write this message.

...

Only 3 flash chips will be supported, W25Q16JV**IM, W25Q64JV**IM, and W25Q128JV**IM. This and so many other design issues still need to be documented. These IMXRT chips have a much more complicated startup process than simpler microcontrollers.

What fun ... or work. Two virgin parts means one test per board where MCU and the FLASH both get altered to limit re-use. Fuses not locked and not write protecting the upper FLASH could allow re-test - extra work and maybe not a true test ... but perhaps still usable - except if bad 15 sec restore code locked in.

That is a nice assortment of sizes - then just need to decide if the 1062 presents as 4.0 or 4.1 ... lots of details and documentation indeed ... the fun never ends
 
Yup. These are all the boards I've tested in one way or another over the last several days. All are in working condition for reuse in projects, but once the fuses are altered, they're no longer a valid test for the actual experience of bringing up a virgin board.

boardstested.jpg
 
WOW Paul - a lot of work to get the bootloader chip working for the T4. Very frustrating that the whole problem was the LED issue! Think they use to call it a sneak circuit :) As @defragster said "the fun never ends" does it.
 
Back
Top