Roll My Own Teensy 4.1 with MIMXRT variant

Status
Not open for further replies.

biomurph

Member
I'm working on a custom PCB based on the Teensy 4.1, and I have a couple of questions.

The Teensy 4.1 uses a 12x12mm MIMXRT chip and the 4.0 uses a 10x10mm MIMXRT chip.
I'd like to use the 10x10mm for space considerations, and it looks like I can do that if I point the right bootloader at it and select the right board variant in the Teensyduino IDE.
Is that right?

Also, because of everything, the MIMXRT1062 parts are rather rare.
However, the chip variants MIMXRT106A, MIMXRT106F, MIMXRT106L are somewhat available.
Are those variants usable within the Teensyduino ecosystem?

BTW, here's a link to the datasheet that describes the variants starting on page 6
 
I also see the MIMXRT1061 with some availability. I can't tell the difference between the 1 variant and the 2 variant at first glance. Are they interchangeable?
 
Yes, Paul. I have that chip already in my toolbox.

My question is about the MIMXRT ARM processor chip. There are a few variants of that and the one that you are using is not available.
Can I use a different flavor of the MIMXRT with your bootloader?
 
Can I use a different flavor of the MIMXRT with your bootloader?

Honestly, I don't know. I haven't tested those chips. There's a chance they may work. If they don't work, no support will be added for them, so best to build just 1 or 2 boards if you want to take the risk to test them.

If you need just a small number of chips for prototyping, we do have a couple dozen of the 12mm chip for Teensy 4.1 left over. As far as I know, all the 10mm chips we had went into Teensy 4.0 production, but we might get more in a few weeks.
 
Wow, thanks for the offer!
I could use a small number of the 12x12mm chips for prototyping with. How do I go about arranging to get some?
More than happy to pay your cost+, of course.
 
Here's some further details on the scope of the question and the weirdness of the problem.
This is a screen shot of the data sheet for the MIMXRT106 family. There are many variants of this chip and the part numbers can make you a bit dizzy.
The part that Paul is using is the MIMXRT1062DVJ6B. All of the parts that end in "A" are gone EOL.

MXRT106 Part Numbers.png

This is a breakdown of the way the part numbering system is structured. Note that some of these chips offer some sophisticated functionality.
In the "Tie" column, there are categories for Voice Control and Facial Recognition of all things.

MXRT106x part numbering.jpg

The only other thing that I can find that explains the real difference between variants is just above this page in the data sheet.
I'm only interested in the "Tie" "Package Type" and maybe the "Core Frequency". Here's a sample of the feature set that Teensy 4.x is using.
The only difference I'm seeing in this "1062" variant is the package size.

MXRT1062 Features.jpg

This is another chip variant, it's actually in stock and a bit more expensive. It offers Facial Recognition and has the same features as the one above.

MSRT106F Features.jpg

I assume that the "F" variant simply has some custom firmware that NXP has cooked up to do the facial recognition and image processing stuff. And that if I shell out the extra dough to get them, I'll be able to burn off the NXP software with the Teensy bootloader and run it just like a Teensy 4.x.
I also know what happens when you assume something...

Anyone got an idea about crossing these part numbers?
I'm also reaching out to NXP, and they are being a bit opaque, but I will chisel away on that front too and if I hear anything I'll put it here.
 
I could use a small number of the 12x12mm chips for prototyping with. How do I go about arranging to get some?

Email me & Robin directly. Write the message *only* about buying a small number of those chips. Mixing business and any tech questions in the same email is a perfect way for it to "slip through the cracks" when we're really busy (which is almost always).

I believe we have more chips arriving next week, so we should be good for low to moderate (under 100) quantity.


And that if I shell out the extra dough to get them, I'll be able to burn off the NXP software with the Teensy bootloader and run it just like a Teensy 4.x.

I haven't tested any of those chips. As far as I know, nobody has.

I also don't have any technical documentation about how they really work. I only know how the normal 1062 part works, and a little info I've read (but not hands-on experience) about the 1064 part. So all the following comments are based only on my 1062-based knowledge.

Hard to imagine you could "burn off the NXP software". With Teensy, the software storage in a separate flash chip made by Winbond. The 1062 chips have no flash memory. NXP can't know whether you will connect a Winbond or Spansion or ISSI or other flash chip, and they certainly have no control over the contents of flash memory you buy from other companies and connect to the 1062. NXP only has ROM and fuse memory inside 1062.

Code isn't possible in the fuse memory. The fuse memory is only 256 bytes and most of it is reserved for specific uses, like stuff NXP stores during testing of the chips, boot configuration, and areas meant for encryption keys. The fuse memory is mapped to the peripheral address space, where we configure the MPU to disallow code execution. Even if the MPU was configured differently and fuse memory large enough for a program, you probably couldn't execute any code from the fuses because the registers are sparsely populated with each 4 byte word mapped every 16 bytes of address space.

While NXP could theoretically put anything inside those chips, the 3 plausible explanations (at least that I can imagine) for embedding software would be repurposing part of the normal ROM, or increasing the ROM size, or adding a flash chip on FlexSPI2, as they do for the 1064 part.

The 1062 chip has many powerful security features which we normally don't use on Teensy 4.x. I'm currently working on support for encrypted firmware, but even that will use only a subset of the security features. NXP has many more capabilities in the hardware, and it's entirely possible the chip has even more (undocumented outside NXP) security features.

But we do know the hardware supports ARM TrustZone. On top of the normal ARM MPU, NXP has a Bus Encryption Engine which is capable of remapping addresses and enforcing access controls. You can see some info about its configuration on pages 367-374 and 377-380. Sadly, most details are in the security manual which NXP only provides under NDA, though a lot of that info is also in their SDK header files which are public.

You can also find mention of memory patch hardware, for example on page 186. Earlier versions of the reference manual showed more mentions. I've not seen any real documentation on it, even in the confidential security manual. It's entirely possible these chips don't have that hardware (but maybe some iMX6 or iMX8 do, and lingering mentions are just leftover copypasta from NXP's earlier documentation on those other chips). Or maybe 1062 has a silicon bug in it memory patch hardware which is "fixed" by deleting all documentation. But it's also entirely possible that sort of hardware is present and could be dynamically patching anywhere in the 32 bit address space.

It's also quite possible the special software isn't burned into the hardware at all. In fact, if I were to wager, I'd bet they probably don't put the special code into the chips at all. It very well could just be a collection of header files and either source code or compiled .o or .a files (likely provided under NDA) which you link with your application.

The software could also be an encrypted "binary blob" rather than normal .o object code or .a library archive. Theoretically, NXP could pre-burn the decryption key in the fuse memory and leverage some combination of the security features I've just mentioned, for you to embed a binary blob into your program and have its functions be callable (but not readable) from your code.

Truth is, I have absolutely no idea how they're providing that additional software. But I do know the hardware has many very impressive security capabilities which can dynamically remap, encrypt and enforce access controls to regions of memory. It's entirely possible NXP might use some technical feature I don't know exists & can't even imagine. If you're thinking of these chips as simple microcontrollers like old 8 bit chips, the range of abilities can be quite surprising.

I still have no idea whether those parts can work. Probably the only way to find out is to build a board and try them. But even that could be risky, as we'll soon be updating the bootloader to support encrypted flash, so if NXP is using special security features together with that special software, there's a risk of future compatibility issues as we support using some of that special hardware.

I'd really recommend going with the 1062 chip. Email us directly next week and we'll probably be able to help you with a small quantity to get your project going.
 
Last edited:
Well then.

Re-mapping access controls and security and encryption tools that the chip has make me wary of trying one of the chip variants that NXP is specifying for-purpose only.
They could easily lock the chip up so that you can't access the parts that they have used.

Here's an example of their hardware and software configurations for the Facial Recogintion (found here) It's something they call "Edge Ready"

FaceHard.jpg

FaceSoft.jpg

I get that these are massively more complex than any low level 16 or 32 bit microcontroller, but to my mind it appears that there is a stack of software running on the chip. They are probably using the HyperFlash and the SDRAM as well. These diagrams are likely for a DK module, but it is possible to buy the stand alone 106F chip, so methinks it's got some of this software already on it.

It is best to use the target 1062 variant, and for larger runs I will have to wait with everyone else for the supply chains to re-connect. Was hoping this would be an easy drop-in.

The only other alternative that I have is a version of the family that runs at 500MHz (nominal. The data sheet specs it at 523MHz). I happen to have some of these chips (MIMXRT1062CVJ5B) and after careful comparison of the overall specs and the pinout, it does look like it is a physical drop-in replacement for the one on the Teensy 4.x.

If it does work, then I guess the best case scenario is that the timing of various clock related functions will be off. That would be a bummer.
 
then I guess the best case scenario is that the timing of various clock related functions will be off.

In Arduino, just click Tools > CPU Speed and choose a lower speed before you compile and upload.

That is, if this chip works at all. Seems likely, but only testing will really confirm.
 
In Arduino, just click Tools > CPU Speed and choose a lower speed before you compile and upload.

Ahh. Have not noticed that option.
My current application is using ultrasonic sound, but I think 523MHz will be fast enough ;)

Got a feedback from the NXP.

> Can I use the variant chip and overwrite the RTOS and other stuff with my own?
-- No, I'm afraid not.

Anyway, it's good to know.
 
Status
Not open for further replies.
Back
Top