Teensy 4.1 bootloader MCU and direct RT1062 Serial Downloader

S

StevenMartin

Member
Hi all,
I'm learning embedded systems from the ground up with a Teensy 4.1, deliberately trying to understand the hardware/software boundary rather than relying on the Arduino/PJRC abstractions. I'm really enjoying digging through the RT1062 reference manual and the Teensy schematic.
I've been trying to understand the purpose of the separate PJRC bootloader MCU (U2), particularly given that the RT1062 itself contains immutable NXP Boot ROM with a Serial Downloader mode.
My understanding is that the RT1062 can be put into Serial Downloader mode via its BOOT_MODE pins, after which the ROM can communicate over USB/UART, download an image into internal RAM, and execute it. NXP's documentation then describes using a RAM-resident flashloader to program external boot flash.
That leaves me with two questions:
What functionality does the separate PJRC bootloader MCU provide?
I understand that it provides the Teensy programming/recovery experience and has additional responsibilities such as power sequencing, fuse configuration, security, etc. But I'm interested in the fundamental reason for having a separate MCU to program the external flash, given that the RT1062 has immutable ROM recovery and external flash can presumably be reprogrammed through NXP's native mechanism. Is there functionality or a limitation I'm overlooking?
Can the PJRC bootloader MCU be bypassed for learning/experimentation?
As a learning exercise, I'd like to isolate the RT1062 as much as reasonably possible and interact directly with its NXP ROM Serial Downloader — ideally forcing the appropriate BOOT_MODE state, resetting the RT1062, and communicating with its USB Serial Downloader from a PC using the NXP SDP protocol, without using the PJRC loader.
Is this physically possible on an unmodified Teensy 4.1, or would it require modifying the board / disconnecting U2? If it is possible, are there particular pins, test points, or reset/power considerations I should be aware of?
I'm not trying to replace the Teensy bootloader for normal use; this is purely a learning exercise. I'd like to start as close to the RT1062 itself as possible, understand the immutable ROM → RAM → external flash boot chain directly, and then work upwards into what PJRC adds.
Thanks to everyone who has helped document the Teensy hardware so well. It's been a very useful platform for learning this stuff.
 
It does some "one-time" programming of the fuses that restricts the bootable mode, assigns a MAC address, serial number, etc. You can't "undo" the fuse settings once they're set so I believe it's stuck booting from flash after a single power-up.
The bootloader also writes unique info (within itself) identifying the MCU (and possibly the flash) so it can't be reused on another unit. It's basically just an anti-clone device.
If you want to play with the IMXRT1062's other boot modes you're probably better off getting hold of one of their eval boards.
 
Last edited:
Unfortunately, this thing also makes settings that prevent convenient debugging.
Okay, it is like it is.
 
The one time stuff makes sense. To be clear, my main goal is learning embedded at the lowest level I can. I realised I already had a Teensy 4.1 from a previous project (lovely piece of tech!), and decided that it might be fun to try and treat it as pure hardware, and see if I can get it working from scratch.

My first step has been reading the RT1062 ref manual which is very dense. I've learned that the CPU has an internal boot ROM, which, if you configure some pins correctly, will jump to 'serial download' mode which will allow you to pull in the NXP flash resident program which can be used to program the external flash. Sounds good!

My goal is to write my own flash loader, just to see if I can do it. I appreciate the comment saying 'probably better off buying an eval board' which is true, but I already have the Teensy.

So my first question was, can I somehow skip out on the teensy bootloader chip doing any programming but still trigger the correct pins to put the RT1062 into serial download mode?

For my second question I was a little confused about why the extra design, manufacturing, and cost would be used to add a separate bootloader chip, when NXP apparently already have a re-usable way to get a program into external flash (granted after the one time setup boot config). I have every faith that PRJC know what they're doing and have every reason to include the chip, which means that my understanding is what's missing.
 
StevenMartin said:
I've learned that the CPU has an internal boot ROM, which, if you configure some pins correctly, will jump to 'serial download' mode which will allow you to pull in the NXP flash resident program which can be used to program the external flash. Sounds good!
Click to expand...
Not if the fuses have been configured to disallow it... or the required pins haven't been exposed on the board.
 
To really work with the 1062 takes not only understanding the ref manual and hardware but an NDA for added materials and support, and years of experience and work.
If it were simple everyone would do what PJRC has done, and the Teensy stands unique with size and power and robust support for Arduino environment, with a bare metal presentation of the device for Arduino or other using the tools and build environment - limited to USB programming through the bootloader.
This effort goes back to 8 bit MCU's and a couple families of 32 bit NXP MCU's

The work exposes as much functionality as PJRC could arrange from the MCU in a uniform Teensy form factor.
The bootloader chip for 1062:
  1. Supports complex power on
  2. Keeps the device from bricking with fuse settings and control of the programming process.
  3. Provides a Restore from Flash with factory Blink when things do get disturbed.
  4. Keeps knock off folks from confusing the PJRC brand with bad clones or just cloning and spoiling years of continued work to support ongoing development.
As noted for self exploration NXP sells an Eval board supported by their toolset.
There are threads on hacking the bootloader out to bypass it for alternate programming and debugging as the fuse settings may allow.
 
StevenMartin said:
if the Teensy 4.1 is setup to allow this
Click to expand...

The official answer is "not really". Teensy is really meant to be programmed by Teensy Loader, either the normal GUI version or the command line tool.

Unofficially, you have more options with Lockable Teensy, which allows setting the boot config fuses. Unlike standard Teensy where the fuse that permanently fixes the boot config is set, on lockable you can write to those fuses. If you set the wrong boot config fuses, you can permanently brick your Teensy. Or really just configure it to a mode you can't use, which for all practical purposes means it becomes permanently bricked.

I really do not recommend setting any of those fuses, other than with the tools we publish for lockable Teensy. Of course, with those tools if you lose your key.pem file, you can never load new code onto any Teensy locked with that key. It doesn't become bricked, but remains fixes with the last programmed code if you no longer have the key needed to create new .ehex files.

Indeed many of the fuses related to security are "reserved" and documented only in the security reference manual which NXP provides with signed NDA. Unfortunately NXP is a huge corporation that just isn't easily approachable for individuals. To even talk with anyone who might approve sending that security manual, you'll probably have to do through people who will ask about your company and production plans using their chips.


StevenMartin said:
To be clear, my main goal is learning embedded at the lowest level I can.
Click to expand...

Focusing your early efforts on the code loading process is probably not the best way to begin learning low level details.

Likewise, creating all your own code from scratch is a very steep hill to climb.

A better way to start diving into really learning low-level embedded programming is to pick one of the peripherals and write your own custom code. For example, maybe start with FlexPWM. It can do so much more than just the very simple PWM accessible by Arduino function analogWrite() and analogWriteFrequency().

Maybe after some success with FlexPWM, branch out to also using it with DMA.

After you're feeling experienced with the simpler peripherals (not that FlexPWM is easy... it has a mind boggling number of features) you might move on to the more complex stuff like USB or SDIO. But these peripherals with built in bus master DMA that implement advanced protocols are far more complex. Best to only dive into them after you have success with the simpler stuff.

Maybe also experiment with the startup code as you learn the peripherals. As your knowledge grows, you'll probably want to customize that startup stuff.

My point is you can control everything that gets compiled into the .hex file, down to the lowest level details of all the hardware. There is so much to learn to do all that. Best to leverage the already-working libraries and tools, so you can learn it incrementally with each new adventure building upon prior success.


But if you *really* want to first attempt to craft your own tools, using NXP's eval board or maybe Lockable Teensy are the ways you can get more control over the boot config fuses. Be careful, as it's easy to end up bricking the hardware, especially if you're experimenting.
 
Looks like NXP stopped making this eval board, but if you really want one for experimentation, some distributors still have stock.

Mouser has 13 in stock today, part number is 771-MIMXRT1060-EVKB

Newark has 19 in stock today, part number 25AK0898
 
T4.1 is a really complex device, and maybe not the best choice to learn embedded "from the ground up". If you start with something simpler, you'll have fewer features and less code to understand, and you can work you way up in complexity. SAMD21 and SAMD51 (formerly ATMEL, not MICROCHIP) are possibilities. I think you'll find boards and development environments that will let you go all the way down to the bottom.
 
You must log in or register to reply here.
Back
Top