Bootloader Chip For Teensy 4.0

+1 on the new bootloader. I've been developing a hobbyist product based around the 4.1 hardware, not realizing that this was not yet supported. I just stumbled upon this thread while looking into other issues. Thanks Paul for all the work you do. Can't wait to be able to order these chips.
 
May I ask how you do solder the i.mx.rt?
I want to try that some day, but I fear it's not that easy.
..and you'll need a 6-layer board, right?
 
I will use a solder paste stencil and my reflow oven. It might be possible with a hot plate or a hot air station, but I wouldn't want to have to depend on that. I've not soldered a BGA chip of this scale yet, but I've been producing boards with fine pitch qfn for a while now. The Teensy four is a 6 layer board. But for my application it looks like I can get away with four layers.
 
It is possible using only 4 layers. But if you want to bring out many of the signals, usually 4 layers means you will need much more PCB area for routing. If you want a physically small board without "wasted" space, you probably need 6 layers. Well, unless you're bringing out only a relatively small fraction of the pins.

NXP's reference board is only 4 layers, and a lot of space around the chip is filled with traces. The early Teensy 4.0 beta test boards were only 4 layers, and they were 0.2 inches wider to allow room for the many wires.
 
If you really need a custom iMXRT1062 design now, then I'd design it for both a MKL02 and a jtag connector.
 
If you really need a custom iMXRT1062 design now, then I'd design it for both a MKL02 and a jtag connector.

This might be possible, but are the MKL02 that we can buy right now compatible with the iMXRT1062, other than the fuse-setting issue?
 
This might be possible, but are the MKL02 that we can buy right now compatible with the iMXRT1062, other than the fuse-setting issue?

Paul has noted that there is no PJRC bootloader chip that can deal with a virgin new 1062. It needs 'prep/setup' currently only done on the Teensy test jig. Even the MKL02's on a shipping Teensy will not recognize a fresh 1062.
 
Paul has noted that there is no PJRC bootloader chip that can deal with a virgin new 1062. It needs 'prep/setup' currently only done on the Teensy test jig. Even the MKL02's on a shipping Teensy will not recognize a fresh 1062.

Yes, I understand that. Not what I'm proposing. I'm wondering if it's possible to set the fuses on a virgin 1062 to mimic what you'd find on a retail T4, and use the MKL02 that I can buy on the website today? I have not looked at every single fuse on my T4s, but so far I have not found any that are read-protected. It would be great if the MKL02 would tri-state the control lines to allow JTAG as discussed in other threads, but as a workaround we could do that in hardware.
 
Yes, I understand that. Not what I'm proposing. I'm wondering if it's possible to set the fuses on a virgin 1062 to mimic what you'd find on a retail T4, and use the MKL02 that I can buy on the website today? I have not looked at every single fuse on my T4s, but so far I have not found any that are read-protected. It would be great if the MKL02 would tri-state the control lines to allow JTAG as discussed in other threads, but as a workaround we could do that in hardware.

... considered adding ... but it is apparent on visiting PJRC: There are no 1062 bootloader capable chips yet for sale on the website.
 
... considered adding ... but it is apparent on visiting PJRC: There are no 1062 bootloader capable chips yet for sale on the website.

Ok that was the part I was most unsure about. I realize the currently available MKL02s can't currently set the fuses, but I had hopes that they supported the 1062 otherwise. Seemed plausible...

Could they be made available, assuming it's up to us to set the fuse bits?
 
Ok that was the part I was most unsure about. I realize the currently available MKL02s can't currently set the fuses, but I had hopes that they supported the 1062 otherwise. Seemed plausible...

Could they be made available, assuming it's up to us to set the fuse bits?

It could likely be done - but the work to create SKU#1 for that isn't trivial and the group of users that could find a way to burn the fuses and then have the bootloader work? Likely lots of support even if the implementation was flawless on the part of PJRC.

Then to create another SKU#2 for the 'finished' product confusing folks and the support for that in addition to stocking them after stopping all else to call SKU#1 version done as a half solution with no support for protecting the code that many volume production folks would want would be wasted effort when current times are keeping PJRC over worked when under staffed ( imposed workspace limits etc.) with current products and support and platform advancement.
 
What would help right now is if Paul can update us on whether this is still something that he is trying to implement or whether it's a dead end in terms of getting a boot loader for 4.x
 
What would help right now is if Paul can update us on whether this is still something that he is trying to implement or whether it's a dead end in terms of getting a boot loader for 4.x

He has posted recently to this effect - on another thread about this IIRC ...

Yes - this related thread :: pjrc.com/threads/57173-Teensy-4-0-code-security

That thread covers the needed feature of the 'bootloader chip' for the 1062. With the external FLASH - to be a usable tool for production boards it needs encryption to prevent access to 'released code'. So the bootloader is held up on that non-trivial sequence navigating with the 1062 and security.
 
He has posted recently to this effect - on another thread about this IIRC ...

Yes - this related thread :: pjrc.com/threads/57173-Teensy-4-0-code-security

That thread covers the needed feature of the 'bootloader chip' for the 1062. With the external FLASH - to be a usable tool for production boards it needs encryption to prevent access to 'released code'. So the bootloader is held up on that non-trivial sequence navigating with the 1062 and security.

Guess I'll either be shelving my project, or rolling back to the MK66FX1M0VMD18. My project targets open source enthusiasts, and has no need for flash encryption.
 
Guess I'll either be shelving my project, or rolling back to the MK66FX1M0VMD18. My project targets open source enthusiasts, and has no need for flash encryption.

My guess is the encryption is needed to protect the PJRC proprietary stuff needed on the 1062 chip to make everything work.

On the offchance that Paul sees this, I'd be willing to purchase both the bootloader and 1062 prepared chips from PJRC; although, I can understand how the technical hurdles to prep the 1062 chips and the time to package and ship everything might be undesirable considering the relatively low volume compared to Teensy sales.
 
Similar interest. Happy to purchase the bootloader and 1062 chips if possible.

Not sure if this should be a separate topic, but given that the bootloader is not available for the 4.1, what are the options to productionize a designed based off the 4.1, besides soldering the 4.1 directly on the board itself? If a bootloader is developed, is it possible to load the hex file compiled in Arduino for the 4.1 directly into the IMXRT chip?
 
Similar interest. Happy to purchase the bootloader and 1062 chips if possible.

Not sure if this should be a separate topic, but given that the bootloader is not available for the 4.1, what are the options to productionize a designed based off the 4.1, besides soldering the 4.1 directly on the board itself? If a bootloader is developed, is it possible to load the hex file compiled in Arduino for the 4.1 directly into the IMXRT chip?

I guess that if you populate JTAG pins, or any other variant that can flash the chip, you can program the MCU in the usual way ith the .hex generated per Arduino IDE.
Correct ?
 
I guess that if you populate JTAG pins, or any other variant that can flash the chip, you can program the MCU in the usual way ith the .hex generated per Arduino IDE.
Correct ?

After studying the schematics, datasheets, and current fuse config, I think this would work with a few caveats. If your product needs encrypted and protected firmware, it would currently be trivial to extract the firmware from the external flash. Also, if your product depends on the open source ecosystem and reprogrammability, you will be cut short by the technical hurdles of uploading new firmware without the bootloader.

One major question is if the Teensy core attempts to communicate with the bootloader once running user code. I have not verified this myself. If so, you might have a problem. But since this is in the realm of the open source Teensy core, it could be worked around with patches.

We've eliminated the possibility of using the currently available bootloader chips with fresh MCUs. We've also eliminated the possibility of using them with MCUs with fuses pre-burned to match that of a Teensy 4.x. This doesn't leave a lot of options if you value the open source or security aspects detailed above.

Personally I've already invested a lot of time in an open-source and developer friendly product that being reprogrammable with arduino is key. So as a short term solution to be able to continue development and integration, I've just ordered a reballing stencil for the MCU. This will allow me to get a few units out the door for testing and further firmware development. But this greatly increases development time and cost, and ultimately I'm still depending on PJRC to deliver on the new bootloader chips. Fingers crossed is all I can say with the available information.

Just brain dumping... Hope this helps someone and lets PJRC know that the gears are turning...
 
On prior Teensy the bootloader was only required to be online during programming - once programmed it could be removed. So there isn't any reason to think there is magic feedback from the bootloader tied into the uploaded code. It has just been a hex sketch doing what was requested with support code as in the open sources.

One note by Paul did suggest that the 1062 may however rely on the bootloader chip to time/delay/trigger the startup to make sure the voltages are as needed to fire it up being a more complex chip as integrated into his design.

No doubt the bootloader chip could easily set the fuses - but that would be an intermediate version and once those fuses are set it could not perhaps then evolve that board into a version where the code is encrypted for use as noted in p#72.

It is certainly a non-trivial task and involves working from limited documentation (not clear nor specific) - with dedicated effort - and bricking boards in the process to make it a saleable product that won't lead to bricking. PJRC progress and preparation allowed the T_4.1 to ship as it did in spite of the pandemic - but those ongoing restrictions are taxing existence with 2 and with effort 3 persons in what would be at least a 4 person business to free Paul's efforts in development.

A sidenote after years working with the previous family of hardware in the 3.x family - it took a year of work to produce a functioning 1050 variant that jumped to this 1060 MCU to make it a non-bricking member of the Teensy Family in the 4.0 then the 4.1 months later. The T_4.1 might have been delayed to make the bootloader work with encrypted flash - in that case there still possibly wouldn't yet be a T_4.1 given the state of the world and current lockdown restrictions. In fact only just recently were update/additional details released by NXP on the HAB and related issues needed to get the progress on that front - that is another thread ...
 
A sidenote after years working with the previous family of hardware in the 3.x family - it took a year of work to produce a functioning 1050 variant that jumped to this 1060 MCU to make it a non-bricking member of the Teensy Family in the 4.0 then the 4.1 months later. The T_4.1 might have been delayed to make the bootloader work with encrypted flash - in that case there still possibly wouldn't yet be a T_4.1 given the state of the world and current lockdown restrictions. In fact only just recently were update/additional details released by NXP on the HAB and related issues needed to get the progress on that front - that is another thread ...

I still greatly appreciate Teensy, Paul, and everything that's being done. It's a hard time. I'm doing my own work to try and find a path to success during this time. So thanks to everyone for sharing information and making this a fun ecosystem to be a part of.
 
Same here, I really appreciate the work put into the Teensy. I built my products around this mainly because of the developer experience. I must have bought over 6000 bootloaders from PJRC already, and am hoping to continue with the 4.1.

I'm just little disappointed that Paul stopped giving any updates on this topic - I think it was in July 2020 that he said it was a few weeks from completion, and then there's no more communication. I'm not asking for a date, but a status update would be good (and I'm not the only one asking). It's a little unnerving running a business built on this.
 
Back
Top