Flashing 4.1 code on a board with a 4.0 bootloader chip

Henrik

New member
Good day to all,

I have a question about flashing 4.1 code on a board with the bootloader chip from Teensy 4.0.
Is this even possible or is there a workaround?

To be a bit more detailed, we are currently developing a more embedded version of the Teensy board for a couple of research projects.
And as I said, we only have the bootloader chip of the 4.0 version, but we would like to integrate some features of the 4.1 version, because both variants are based on the same IMXRT1062 chip.
With features I mean, for example, a higher number of GPIOs and ethernet support.

By the way, we are working with the Arduino IDE and it would be good if our board is shown there as a new board.

So far I've figured out that it has something to do with the "imxrt1062.ld" or "imxrt1062_t41.ld" file and of course the board selection in "boards.txt".
But I'm not sure if that's all and I'm stuck there now...

Many greetings from Germany
Henrik
 
If you're building your own PCB with the T4 bootloader chip, simply use the W25Q64*M flash memory. The T4 bootloader chip automatically detects which flash memory you connected. It will act at Teensy 4.1 if you have a W25Q64*M flash memory.
 
Teensy 4.x as System in Package

If you're building your own PCB with the T4 bootloader chip, simply use the W25Q64*M flash memory. The T4 bootloader chip automatically detects which flash memory you connected. It will act at Teensy 4.1 if you have a W25Q64*M flash memory.

Thank you very much for the reply. We have already built the first Eval Board from Teensy with the components we received from you and it worked as expected.


The only problem is that we can't use the features of TS 4.1 because of the flash chips. Is there any software workaround to program it as TS 4.1?
If not, could you provide us with the W25Q64*M flash memory used for the TS 4.1?

Cheers,
Basel Adams
 
Ok, I'm hearind that you've built a custom PCB with the W25Q16*M chip, so it identifies as Teensy 4.0, but you've connected more hardware similar to Teensy 4.1. Is that right?

Or are you still in the planning phase, not actually made the PCB yet, so this is a hypothetical "what if" type question?

There are a couple ways you could try to solve this problem.

1: Delete the .elf file before uploading. Teensy Loader looks at the .elf file to know which board you selected in the Tools > Boards menu. Without the .elf, it will just blindly load the .hex data without any check whether it was created for the board you actually have connected.

2: Edit "_teensy_model_identifier" in .ld for the board you've selected in Tools > Boards. This sets the ID number which Teensy Loader finds inside the .elf file.

3: Edit boards.txt to customize how Arduino compiles the code.

4: Edit various library source code to suit your specific needs. There is no single simple answer, as the core library and other libraries have many features. Exactly what you would change depends on the details.
 
I tried your first point with deleting the .elf file and it works.

I also made a copy of the "imxrt1062_t41.ld" file and changed the value "_teensy_model_identifier = 0x25" to "_teensy_model_identifier = 0x24".
In addition I created a new board profile in "board.txt" based on the 4.1 profile but with the modified .ld file.
This also seems to work and we can now use the additional analog pins from the 4.1 design without any further major changes.

So many thanks for your help and your quick responses!

Greetings from Berlin, Germany.
 
Sorry for bumping an old thread, but it answers some of my questions, but I have a few more.

1. Can I use a working bootloader from a Micromod on a fresh IMXRT chip for testing purposes, or would I need a fresh bootloader too?
2. Can I user a larger Windbond flash chip than the 128Mbit on the Micromod?
3. If I want to use more pins that are not exposed on any of the Teensies, do I have to alter the core files and relevant libraries to support this?
 
1. 2. - Obviously best for Paul to answer. - My guess on 2. Is the bootloader code is probably looking at things like the size of the Flash chip to know which Teensy it is... So may be an issue. But again just throwing a dart.

3. - The obvious answer is, it depends. That is if you wish for standard libraries and the like to work with these additional pins, then yes.
That is if you wish to do something like pinMode(my_new_pin, OUTPUT) or analogRead(my_new_pin), or the like, than yes they need to be defined in the places that use them.

If however, if you wish to address them by the internal registers, then you are free to define them or not to define them.
 
Quick answers

1: Fresh bootloader chip needed

2: No

3: Yes. Or you can just access the IMXRT's GPIO and IOMUX registers directly if you wish to avoid editing the core library.
 
Thanks both for the responses. It confirms what I thought and understood already from the documentation and some forum posts.
My goal is to create a hybrid between the T4.1 and MM - I have almost all the pins I need on the MM for peripherals (CAN, I2C, FlexIO, GPIO's) but I would like to add on the PSRAM that the 4.1 has as well as the external flash memory.
So I guess I would need to edit some of the core files to support this?

I'm using PlatformIO so it might be easier to copy the TD framework plugin and work on it rather than modify the original version I have install. But if possible would like to know what files in the core library are one I should defiantly need to edit for basic usage of PSRAM and perhaps external flash that's found on the T4.1?
 
Is the only T_MM feature and change needed support of larger Program Flash?

For PSRAM and those 4 bit SPI pads and memory setup would seem starting from the {local}\hardware\teensy\avr\cores\teensy4\imxrt1062_t41.ld file and using the core code with the IFDEF for T_4.1 in startup to enable PSRAM would be the easier path.

Search the CORES sources for the ARDUINO_TEENSY_MICROMOD .vs. ARDUINO_TEENSY41 #ifdef will show where they have changes. And each has a unique .LD file and altered boards.txt settings.
 
Note: Some sketches/libraries may check for ARDUINO_TEENSY41 before they check/use PSRAM. And likewise, might check for which Arduino they are running on to decide what they are going to do in some cases. Example for cameras they may decide to use FLEXIO on MMOD and CSI on T4.1...
 
But if possible would like to know what files in the core library are one I should defiantly need to edit for basic usage of PSRAM and perhaps external flash that's found on the T4.1?

For PSRAM, edit startup.c. Look for the configure_external_ram() function and the #ifdef check Kurt mentioned.

For external flash, you would use the LittleFS library, creating a LittleFS_QSPIFlash instance in your program. There's really nothing in the core library in need of editing.
 
Thanks all for the responses. This is clear to me now.

@PaulStoffregen I have a question specifically for you.
I need pin GPIO_B0_13 for FlexIO2/eLCD interface, but it's used by the bootloader for DEBUG_SWO.
Is there an alternate pin that can be used for DEBUG_SWO? And if so, can it's configuration be changed in the core library or would that require custom code on the bootloader(which I understand won't happen)?
 
There is no perfect answer regarding use of GPIO_B0_13 (BGA pin D10) on a custom PCB using the T4 bootloader chip.

If you really need it, the imperfect answer is to just route it to your hardware and leave the PTB4 (pin 12) on the bootloader chip unconnected. Today bootloader versions 1.07 and 1.08 aren't making any use of that pin. I can't make any promises about future versions, which is why this answer is imperfect.
 
For PSRAM, edit startup.c. Look for the configure_external_ram() function and the #ifdef check Kurt mentioned.

For external flash, you would use the LittleFS library, creating a LittleFS_QSPIFlash instance in your program. There's really nothing in the core library in need of editing.
Coming back to this as I did successfully test it last year, but stopped there.
Can I take the function configure_external_ram() as well as the smalloc.c/h and put them in my project folder and call configure_external_ram in the setup function? Or is that too late?

I will also use a custom linker file to accommodate the param on the Micromod (doing it in PlatformIO)
 
There is no perfect answer regarding use of GPIO_B0_13 (BGA pin D10) on a custom PCB using the T4 bootloader chip.

If you really need it, the imperfect answer is to just route it to your hardware and leave the PTB4 (pin 12) on the bootloader chip unconnected. Today bootloader versions 1.07 and 1.08 aren't making any use of that pin. I can't make any promises about future versions, which is why this answer is imperfect.
@PaulStoffregen: Is this still true for the current bootloader version (as of 2024-01-31)?

Or would it be better to use a digital bus switch, for example Toshiba TC7WB67CFK, to ensure it is connected (and other functions for the B0_13 pin disconnected) by default during bootup, and only disconnected (and other functions connected) after bootup by application code?
 
Last edited:
I can confirm the above, it can be used as we did disconnect from the bootloader on the dev board.
I used it as a FlexIO pin.

But as Paul mentioned when I had initially asked, it’s usage for the bootloader could change in the future
 
Yep, I'm fully aware it might change in the future. As I explained above, I do have a way to work around it, by using a two-bit bus switch with inverted enable, so that a GPIO pin that is floating or low at startup (like B0_12, pin 32, which defaults to a 100k pull-down) enables the bootloader connection, but switches to the application pin when that GPIO pin is pulled up. The components cost about 0.5€ in singles at Mouser, so it isn't expensive. But, omitting this for now, I have better chances –– fewer possible failure points –– to make my first 6-layer BGA board work.
 
Back
Top