How does bootloader determine if Teensy 4.0 or Teensy 4.1 for custom board?

ctadlock

Well-known member
I just built a custom Teensy 4.x and its all working great. What I was surprised at is when I ran the first blink sketch I had to compile as Teensy 4.1. What configured this as a 4.1 vs a 4.0? As far as I know its the same bootloader chip for both, so I presume its in the logic of the bootloader chip. Size of the flash memory? Ive read through the original long thread about the custom bootloader and dont see anything in there.



error.jpg
 
Size of the flash memory indeed. If you use a 16MB flash it will think it's a Teensy Micromod.
Out of curiosity isn't that an issue? If I used smaller flash would I then not be able to access the higher pins that are only available on 4.1? I haven't looked through the core code for what conditional logic is based on this.
 
Out of curiosity isn't that an issue? If I used smaller flash would I then not be able to access the higher pins that are only available on 4.1? I haven't looked through the core code for what conditional logic is based on this.
Looking at the core code there is a bunch of logic that is conditional on ARDUINO_TEENSY41. Seems like this should be documented on the bootloader page.
 
I think most of the time when people build their own boards, it's for the purpose of specifically exposing different pins that the default products do not. So editing core_pins.h is required regardless of the flash size.
 
Last edited:
I think most of the time when people build their own boards, it's for the purpose of specifically exposing different pins that the default product do not. So editing core_pins.h is required regardless of the flash size.
That seems like an odd assumption. I have no real knowledge why other people are making custom Teensy's though. For me I needed a compact board.

Either way this information should definitely be on the custom bootloader page. I almost used the smaller flash memory chip and if I did I would now have to completely change my software side to handle the custom core.
 
There's also the alternative of simply fooling the uploader so it uploads the hex regardless of the attached model - deleting the .elf file should be enough, since it uses that to check what the target hardware is. Or else you can make a single edit to the linker script so binaries get "tagged" with a different target model.
 
I wish that there was variant support within the Teensy board setup!

I have a fork/branch that I setup earlier to play with the @Dogbone06 boards. I had different variants setup for the
DevBoard4 and the DevBoard5, both of which appear the same as the Micromod. My support was not complete, but it
did allow me to have different pin tables and the like.

I updated some of the subsystems, like Serial ports and the like, but there were some external sub-systems like SPI and Wire which
may not have been.

I updated some of my own libraries, like FlexIO_t4, to instead of having the code with #ifdef <teensy name>
with lists of valid pins and mappings, I instead have the library know all of the possible IMXRT pins that can be flexio pins, and when the
user code asks to use some Arduino pin, it maps the Arduino pin number to the IMXRT Port/pin...

Some of this is probably broken or out of date, as I have been off playing with some other setups. It is also unclear how much, if any,
of this will be integrated into the main Teensy code base. Time will tell...
 
I'm still unclear where the determination of board type is happening. Is it?

1. In the boot loader and it says "I'm a teensy 4.1" and then the software compiler reacts to that

2. In the compiler logic that introspects the hardware (size of flash), determines which variant and then reacts to that

3. Something else
 
Maybe it's a bit confusing because there are 2 separate groups of config, basically software on your PC and the hardware you've connected. They meet when Teensy Loader tries to write to the hardware. If they're different, you get this File Compatibility Error message.

sc.png


So as we talk of the many small details, keep the simple big picture in mind. It's not 1 setting. The settings are in 2 categories, purely software on your PC versus the physical Teensy hardware.

On the hardware side, the Teensy 4 bootloader looks at the flash chip. Older (now discontinued) models looked at which microcontroller. Since all Teensy 4 models (so far) use the same microcontroller, the bootloader looks at the hardware (which it can identify) which actually differs, which is the flash memory chip.

On the software side, if using Arduino IDE the setting is selected in the Tools > Board setting, or from the detected hardware drop-down list in the newer Arduino IDE. That setting in the IDE causes the compiler to be run with various command line parameters. Normally you don't see this, but you can with "Show verbose output during compilation" in File > Preferences. Some of those parameters define names like ARDUINO_TEENSY40 and __IMXRT1062__. Others select which linker script is used. Inside each linker script are special symbols defined. The compiler puts this info into the .elf file. But is does not become part of the actual binary data written into Teensy's memory, so it's not inside the .hex or .ehex file.

Teensy Loader reads both the .hex file and (if present) the .elf file. If checks whether both have the same binary data. If they do, it looks for that extra info which came from definitions inside the linker script. This is how it "knows" which Teensy you meant to program. That's all on the software side... a lot of small details because the software is collection of separately developed tools (Arduino IDE, gcc toolchain, Teensy Loader).

The hardware side is relatively simple. Teensy's bootloader communicates which hardware using a byte in the HID descriptor. Teensy Loader just reads the HID descriptor info to know which hardware you have.
 
I've made a ton of custom boards. To my knowledge there is no way to detect custom or not. I based all designs on the Micromod as it is the most "powerful" Teensy. But my custom boards also has almost all pins exposed. But that's a different story.

All my custom boards appear as a Micromod. But if you change the Hardware ID for the USB it wont be detectable by Teensyloader. And instead you can use FlasherX. This "hides" what hardware it is that you're selling.
 
I've made a ton of custom boards. To my knowledge there is no way to detect custom or not. I based all designs on the Micromod as it is the most "powerful" Teensy. But my custom boards also has almost all pins exposed. But that's a different story.

All my custom boards appear as a Micromod. But if you change the Hardware ID for the USB it wont be detectable by Teensyloader. And instead you can use FlasherX. This "hides" what hardware it is that you're selling.
So what hardware config makes the bootloader think its a Micromod?

It baffles me this information is not on the bootloader page.
 
Out of curiosity isn't that an issue? If I used smaller flash would I then not be able to access the higher pins that are only available on 4.1? I haven't looked through the core code for what conditional logic is based on this.
As I understand it, if you use a smaller FLASH, then it simply would not be a T4.1.

Mark J Culross
KD5RXT
 
As I understand it, if you use a smaller FLASH, then it simply would not be a T4.1.

Mark J Culross
KD5RXT
None of these custom boards "are" a Teensy 4.1 in reality, only in the logic of the bootloader.

Hopefully the people designing future custom boards find this post so they don't blindly make a mistake.
 
This seems like required reading for anyone developing a custom board. Should be included on this page.

That page references the thread where development of the bootloader chip was discussed (you did read that thread, right ?!?!?). The definitive method of distinguishing between T4.0, T4.1, & TMM can be found in <Post #200>.

Hope that helps . . .

Mark J Culross
KD5RXT
 
That page references the thread where development of the bootloader chip was discussed (you did read that thread, right ?!?!?). The definitive method of distinguishing between T4.0, T4.1, & TMM can be found in <Post #200>.

Hope that helps . . .

Mark J Culross
KD5RXT
"you did read that thread, right ?!?!?" - dont be that guy
 
@ctadlock: I don't know what "that guy" is that you refer to. You asked a question (how does the bootloader chip distinguish ??), and the answer (by the FLASH size) is actually provided in several different forms & in several different places. You seem to take offense at my asking a very straightforward & valid question. If that's being "that guy" I guess I'll assume that the shoe fits. I don't really have a dog in this hunt. I was just trying to be helpful, as others have for myself & many others in the past on this forum. This is a great forum with lots of knowledgeable individuals who willingly give their own time to help others. You won't find that in very many other places.

Since I was able to find the answer to your question (with some reading of the indicated sources), and you say in your very first post that you "read through the original long thread about the custom bootloader and dont see anything in there", it seems reasonable that you would probably also have seen the same answer, but it just didn't stick, or something. You were looking for required reading, well, now you have it...again. Could the specific use of the FLASH size to distinguish between the different T4 models be more prominent on the bootloader page, probably.

I don't claim to be speaking for @PaulStoffregen here, but you surely understand that his primary business is creating & selling Teensy products. It is merely a testament to his kind spirit & his appreciation & support for the DIY community that he even makes the bootloader chip available. Be thankful for what is given. If you made a bad assumption, fix it, as you certainly have the information to do so.

Mark J Culross
KD5RXT
 
distinguishing between T4.0, T4.1, & TMM can be found in <Post #200>.
Interesting 2021 @defragster reference post @kd5rxt-mark :)
I've been wondering what to add as post #2 made the note.
PJRC presenting similar info - on the bootloader page would be good. But doing a non-Clone DIY board requires a great deal of research.

Note - IIRC:
The HARDWARE presents its view of itself based on the FLASH size seen on first INIT. That shows in Loader Verbose as noted.
The USER chooses how to build/name the software - mostly comes from the IDE #define that chooses what ???1062.LD file that holds the ID

The BUILD process is fungible where the LD file used and its contents can be altered to present in the DIY configured way.
PJRC software supports T_4, T_4.1 and T_MM and adjustments in DIY are up to the developer.
@Dogbone06 made a T_MM identified variant (16MB Flash) adding 32MB of SDRAM and exposing markedly different pin set and features having little to do with the T_MM - except using the SFUN published PCB layout for a start - combining the NXP SDRAM wiring and additionally bringing out 2 PORTS worth of pins. It takes customization and the IDE builds working HEX even though it has vast differences from the T_MM presenting SDIO SD card and USB Host in addition to the integrated SDRAM. I've not seen follow on in house variants that include other T_4.1 features as well.
@KurtE did create an alternate CORES tree for Variants to allow build control and access to pins as connected for that SDRAM board.
 
Just to be a bit more specific, the bootloader looks at the flash chip's response to the JEDEC ID (0x9F) command. Both the flash memory size and which Teensy model is learned based upon that response.

I need to make a few other edits to those pages. @ctadlock can you suggest the specific edits I ought to make (if any) to resolve the problems you have encountered?
 
Just to be a bit more specific, the bootloader looks at the flash chip's response to the JEDEC ID (0x9F) command. Both the flash memory size and which Teensy model is learned based upon that response.

I need to make a few other edits to those pages. @ctadlock can you suggest the specific edits I ought to make (if any) to resolve the problems you have encountered?
Id probably add a new section right under "Supported Chips" titled "Determination of Teensy Variant" or something that states that the bootloader is responsible for reporting the variant of the Teensy and it does so by an introspection of the flash memory size; and then a table of flash memory size and the resulting variant. The post 2 up from here by defragster has some additional good information that could be added.
 
I have added these words in the Supported Chips section.

The flash memory chip used determines which Teensy model the bootloader will identity. For example, use of W25Q64JVSSIM will make your custom board appear as Teensy 4.1 in Teensy Loader.

I really don't see this as meriting its own section, as it fits pretty well in Supported Chips. Hopefully these 2 sentences are clear enough to fully resolve this issue?
 
Last edited:
  • W25Q16JV*IM (Winbond) : bootloader Chip will identify as T_4.0
  • W25Q64JV*IM (Winbond) : bootloader Chip will identify as T_4.1
  • W25Q128JV*IM (Winbond) : bootloader Chip will identify as T_MM
 
  • W25Q16JV*IM (Winbond) : bootloader Chip will identify as T_4.0
  • W25Q64JV*IM (Winbond) : bootloader Chip will identify as T_4.1
  • W25Q128JV*IM (Winbond) : bootloader Chip will identify as T_MM

Yes, this is more specific. But it also adds quite a bit of extra stuff in an area that was written to address one of the most painful problems people historically encountered. Since that list was added and the words about the Q version specifically not working, we've had little to no reports where people purchased and soldered the wrong chip. I'm pretty sure you can remember the days when we saw those forum messages pretty regularly. I'm reluctant to add this sort of extra detail to that simple list which serves such an important purpose. I really want to keep the top info simple and clearly focused on helping people choose compatible parts, because we've seen over and over how so many people buy the wrong parts if that info isn't extremely clear and prominently displayed.

Later I might add another section farther down on that page about customizing the core library. Main focus would be on extending digitalWrite and other functions. That's a question that comes up pretty regularly. Some of this stuff about which board configured on the PC side might also belong there. But that's work for another day. Right now I'm only making small edits.
 
Back
Top