Bootloader Chip For Teensy 4.0

[mah]

I notice that there is serious interest in a Teensy 4.x hardware debug environment. I and my partner are.....

Im quite interested! But Im quite new to all of this. But I have started creating my own schematic from pauls schematics. And also borowing some stuff from the micromod t4 by sparkfun

My main reason is that I need a micromod teensy with ethernet, and debugging if I ever want to move beyond arduino

 

[mah]

Does anyone know whats the part number for the crystals on the t4/t4.1

I have Google what I could read on top of the package but can't find anything

 

[Frank B]

Note, there is a newer revision (Rev.4 10/2019) of the Hardware Development Guide on the NXP website than the one mentioned here: https://www.pjrc.com/store/ic_mkl02_t4.html (which is Rev 0).
Needs registration and login.

 

[tyzjames]

Is this still in the "soft-release" stage, or is it ready for production-level quantity?

 

[PaulStoffregen]

Yes, full production release.

 

[teosegura13]

Hello,

Was it every confirmed if the revision "B" works? to be more specific: Does the MIMXRT1062DVJ6B work if soldered to a PCB with the boot loader chip form PJRC? (As a teensy 4.1)

Thanks in advance

 

[criznach]

Has anyone had luck getting a custom board to work? I ordered 5x MKL02 chips in early April and built my first board back in May but haven't had a chance to try the first bring up until now. Initially I had a short under the IMXRT and replaced that with a fresh one (revision B). Then I verified the power up sequence steps 1-8 and all match what's described on the product page.

I foolishly did not include the debug LED or program button on the first revision of my board, so these are bodged in with enameled wire and glued down with UV mask. After adding the debug LED, I get no LED output, and no USB enumeration.

I've verified that pin 3 rises to 3.3V, but pin 10 does not go high.

I do see ~1.15V on the inductor.

Next I tried briefly grounding the program pin 10 and releasing. Then I tried holding it low for 15 seconds and releasing. I tried these in several combinations with and without disconnecting power between and after, but still no LEDs or USB enumeration.

One possibility I have not checked yet if my board is booting but I have a short on D+ and D-.

Have I missed anything? Any scope traces that may help? I plan to do a board rev, so I'll definitely add the program button and debug LED. And better test points. But I'd like to isolate the problem on this rev first.

The design is open source but I'm not quite ready to share it with the public yet. If it helps I can share pictures and files privately.

 

[Spencez]

I've verified that pin 3 rises to 3.3V, but pin 10 does not go high.

That is a problem. Pin 10 should be pulled high by the MKL02. If this is LOW, I believe pin 9 will also be low which is your power on reset. This means the processor is being held in reset and it will not run your program. You mentioned you added in a button, could there be a short on this pin?

You probably also would not see the led blink once after 15-25 or so seconds (indicating recovery) because of the following, unless pin 10 worked properly before or if Paul tests them before sending them out.

When the program button is pressed for 15 seconds, the rest of the flash chip is erased and this LED blink is copied to the beginning of the flash memory. Because this copy is created on the first non-15-second press, the 15 second press for restore only works if a short press for normal bootloader entry has been done at least once.

 

[Frank B]

Do you have the red bootloader LED?

 

[PaulStoffregen]

I've verified that pin 3 rises to 3.3V, but pin 10 does not go high.

I can confirm the bootloader code enables the pullup resistor on pin 10 (PTB2) at the very beginning of the startup process, long before it tries to drive pin 3 (PTA3) high when it believes 3.3V power is stable.

Look for a hardware issue with whatever you've connected to pin 10. Perhaps with the power off measure resistance (with multimeter set to highest resistance range, or auto-ranging). On a Teensy 4.0 board, I get approx 8M using a Fluke 87-III multimeter, with the positive lead on the Program signal and negative lead on GND. Your result may vary depending on whatever test current your meter's highest ohms range uses. But the point is you should see a pretty high impedance, but not infinite because there is some current path through whatever ESD protection the MKL02 has on pin 10. If you get something under 10K, you can be pretty sure you have a problem with your board pulling that pin low. If you measure infinite, that's a pretty sure sign pin 10 isn't soldered.

Because you're seeing 3.3V on pin 3, I'm pretty confident your MKL02 is running and you probably have a hardware issue with the connection to pin 10.

 

[PaulStoffregen]

Was it every confirmed if the revision "B" works?

Just to make sure this old question is answered, yes, the B version chips (both 12mm and 10mm size) are confirmed working. The web page was updated some time ago to clearly state both are supported.

 

[criznach]

Thanks Paul and Frank. Very good info and I am fairly certain it's an issue in my design or assembly.

No LED at all. And I will look more closely at pin 10. I have several stock 4.1s I can compare to.

Paul, one thing that would be helpful documentation-wise is the order that the bootloader does things in. For example, is the LED sequence displayed after pins 3 and 10 are initialized, or can we deduce that certain error codes mean that other initialization steps are already done? Let me know if there's anything I can help with as I'm working on it.

 

[PaulStoffregen]

For example, is the LED sequence displayed after pins 3 and 10 are initialized, or can we deduce that certain error codes mean that other initialization steps are already done?

I hope you can see by reading the blink code descriptions that all of them are various ways communication can fail between the 2 chips.

Pin 3 is part of the powerup sequence. Pin 10 is initialized pretty much within the first couple instructions the MKL02 executes. While not explicitly stated on the web page, the entire powerup sequence happens before any communication it attempted.

 

[criznach]

I hope you can see by reading the blink code descriptions that all of them are various ways communication can fail between the 2 chips.

Again, all good info. Thanks Paul. I'll be looking at it tonight with a brand new microscope!

 

[criznach]

I see part of the problem. I put my reset bodge wire on pin 12 not pin 10. Haven't checked for the pull up yet, but I'm sure that's at least part of the problem. Should be easy to test. And if that's all, easily fixed with a board rev.

 

[siniarch]

@paulStoffregen
Just wanted to share the product I created with your wonderful Teensy 4.1. Thanks for all your hard work. About to order 20-30 bootloaders for my first batch of units.

 

[mlewus]

Congratulations, looks like a very interesting product. That is a lot of I/O for one microcontroller

 

[siniarch]

Congratulations, looks like a very interesting product. That is a lot of I/O for one microcontroller

Thank you Mlewus. It's a testament of how well the Teensy 4.1 microcontroller was designed. We utilized almost all it's capabilities. We started with Teensy 3.6 and move to 4.1 because we kept adding features. I'm very pleased with it. Wish it had more memory but we were able to tweak some things and capture more memory from another part of our project that was being wasteful.

 

[siniarch]

I hope you can see by reading the blink code descriptions that all of them are various ways communication can fail between the 2 chips.

Pin 3 is part of the powerup sequence. Pin 10 is initialized pretty much within the first couple instructions the MKL02 executes. While not explicitly stated on the web page, the entire powerup sequence happens before any communication it attempted.

Hi Paul,
Not sure if you saw the video I posted before with the product we made with your microcontroller?
I had another question for you. We can't seem to find a supplier for DP83825 chip (for network jack). 1) do you know of anyone that still has these in stock? 2) if you don't and you had some extra stock, could I buy 10-20 (if it's not too much to ask) from you? 3) if not, can you suggest a substitute to this chip. My developer wanted to ask before we embark on looking for a replacement and having to re-design our entire PCB board.

thank you so much for any info you may provide us.

 

[criznach]

Just wanted to share the product I created with your wonderful Teensy 4.1.

This is really awesome. It's late so I had to skim through, but I plan to watch the whole thing tomorrow. My project is sitting idle while I search for parts for use in my day job. Parts shortages have really been a pain for my clients. I feel your pain.

 

[siniarch]

This is really awesome. It's late so I had to skim through, but I plan to watch the whole thing tomorrow. My project is sitting idle while I search for parts for use in my day job. Parts shortages have really been a pain for my clients. I feel your pain.

Yes, it is incredible how parts have become unavailable. Sometimes for 40-50 weeks.
I do hope things change soon, or this will become a very difficult venture for me.

 

[MarkT]

Its all too credible that just-in-time supply chains are very brittle to unexpected disruptive world events,
since by its nature nearly everything is on the critical path leading to cascades of delays and shortages.
You need slack in a system to be robust.

 

[tyzjames]

I noticed that the 4.x bootloader is "temporarily discontinued" due to some feature development. Is there any ETA on when it might be back for sale?

 

[biomurph]

bootloader for MicroMod instead of 4.1 ??

I just got my custom PCBs based on the T4.1 on Thursday.
Went through the proofing and testing of the power supplies and everything appears to get the juice it needs.
Then, I went to do the initial flash of the MXRT. I used the blink example sketch, as I added an LED on pin 13.
I compiled for the Teensy 4.1, and the Teensy Loader applet popped up right on time. Then, I pressed the 'program' button.
There was a brief (too brief?) message from Loader saying something about how the hardware was not recognized...
eeeep!
Much hair pulling and head scratching ensued, and then I noticed that Loader was trying to tell me something.
It was toggling between it's own splash screen and some other image of a red board with the words 'MicroMod' barely legible...
I was out of the loop about MicroMod, but I did find the variant in the dropdown of available Teensy boards, so I selected MicroMod, recompiled, and presto! I got the blink sketch loaded!

I'm super happy and super confused at the same time.
I ordered the T4.1 bootloader chips, and they arrived labeled that they are Teensy 4.1 bootloader chips, but they show up in the Arduino IDE as MicroMod and won't behave as T4.1.

System: Mac OS
Loader: v1.54
Teensyduino v1.8.15

My hardware is connected to the USB D+ and D- and GND, and I'm using a separate power supply so the USB Bus voltage is not invited to the party.
Did I get the 'wrong' bootloader chip?
Does it matter?

The hardware I've built is an early prototype version for the Tympan project.
I'm able to compile advanced example sketches from the Tympan library whilst targeting the MicroMod, so I think I'm in the clear.

Are there any 'gotchas' that I need to watch out for if I'm using T4.1 developed code on the 'MicroMod'? Are all of the alternate pin functions available in the MicroMod board variant?

I am super grateful to the community here for making custom hardware development with Teensy fun and 'easy'. I'm always blown away when I get a board from my assembly house and it just works. 'Yall rock!

 

[defragster]

I just got my custom PCBs based on the T4.1 on Thursday.
Went through the proofing and testing of the power supplies and everything appears to get the juice it needs.
Then, I went to do the initial flash of the MXRT. I used the blink example sketch, as I added an LED on pin 13.
I compiled for the Teensy 4.1, and the Teensy Loader applet popped up right on time. Then, I pressed the 'program' button.
There was a brief (too brief?) message from Loader saying something about how the hardware was not recognized...
eeeep!
Much hair pulling and head scratching ensued, and then I noticed that Loader was trying to tell me something.
It was toggling between it's own splash screen and some other image of a red board with the words 'MicroMod' barely legible...
I was out of the loop about MicroMod, but I did find the variant in the dropdown of available Teensy boards, so I selected MicroMod, recompiled, and presto! I got the blink sketch loaded!
...

What FLASH chip is on the PCB? AFAIK it is that chip may be the determining factor: T_4.0 @2MB, T_4.1 @8MB and T_MM at 16MB
That is based on this from Paul yesterday - the Flash SIZE and build intent are different - but concept seems the same:

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.

This page pjrc.com/store/ic_mkl02_t4.html only calls out the 2MB and 8MB chips- but if the 16MB was used it is recognized as T_MM.

With the BOARD selected for building it will pick that .ld file and have all the #ifdef's declared for those PIN and MCU attachments. So it seems for T_4.1 emulation some mixing and matching may be needed.

Current last note on above linked thread - for an alternate case - Paul added this as far as mixing and matching:

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.

So if it is a 16MB Flash on your build being ID's as T_MM - then building as T_4.1 and using option #1 removing the .elf might be the proper path.

NOTE: This is just a ref until PJRC might see this. It would be interesting to know if the 15sec Restore works properly? Given the BLINK worked from IDE - then that should hopefully work as well?

BONUS ADDED NOTE: In Teensy Loader using menu 'Help / Verbose' will open a window showing what the Loader documents for its actions that may provide some insight/ref info.