Teensy 4.1 Debug Mod Project

Spencez

Well-known member
I have been working on a Teensy 4.1 debugger mod for a month or so now and I figured it was in a good place to share my progress. This project started by de-soldering the MKL02 chip, soldering magnet wire onto each pin of the MKL02 and the Teensy to break them out to 16 pin headers on a breadboard. From there I jumpered the pins which were necessary for the teensy to function while leaving the J-tag pins free to be used by a J-Link.

teensy 4.1 mod 2.jpg
teensy 4.1 mod 1.png

I was successful in programming and debugging using PlatformIO so I continued the project by designing a flex pcb which could be soldered onto the teensy QFN pads. This first attempt failed as too much of the pads were cut and upon soldering they came right off.

teensy fail 1.png

Which brings us to the current revision. Fully functioning Teensy 4.1 debugging!

teensy debugger 1.png
teensy debugger 2.png
teensy debugger 3.jpg

If you see this Paul, I would love for debugging on the next Teensy to be a bit easier! Although this has been an interesting/fun project to work on so thanks for that.
 
This is very cool. Never seen someone take out a IC like this, that's quite clever :)

Any chance of releasing the files or selling these PCBs?
 
Maybe PJRC should make a debug version. It's easy for a debugger to save $100 in time.
 
Hello Spencez,

nice work.
I also plan to add a JTAG access to the teensy 4.1, but I would prefer to re-program (in-situ) the KL-02 chip.
Could you tell me whether it is protected against full erase or not?

Thank you!
 
This is very cool. Never seen someone take out a IC like this, that's quite clever :)

Any chance of releasing the files or selling these PCBs?

I will probably upload the files and/or post it on OSHPark. It requires hot air, good soldering skills and flux.

Maybe PJRC should make a debug version. It's easy for a debugger to save $100 in time.

I would love if they did this. I feel as if they are waiting until they make the switch from Arduino IDE to bother with debug capability.

Hello Spencez,

nice work.
I also plan to add a JTAG access to the teensy 4.1, but I would prefer to re-program (in-situ) the KL-02 chip.
Could you tell me whether it is protected against full erase or not?

Thank you!

Sorry, I am not sure on this one. I don't have an easy way of getting to the SWD pads at the moment. Worst case you have to buy a new chip and solder it in. That sounds like a project, I hope you figure it out!
 
but I would prefer to re-program (in-situ) the KL-02 chip.
Could you tell me whether it is protected against full erase or not?

I can confirm PJRC does not protect the MKL02 from mass erase. You can erase it to wipe away the PJRC bootloader, if that is your desire.

Of course if you do erase the chip, the only way to restore your board would be to desolder the erased chip and solder a pre-programmed chip in its place.
 
So if I was to wipe the MKL02 and solder a JTAG connector to the relevant pins then the Teensy can be flashed and debugged over JTAG and the only downside would be that the teensy flasher app would no longer work, apart from that everything stays the same?
 
I can confirm PJRC does not protect the MKL02 from mass erase. You can erase it to wipe away the PJRC bootloader, if that is your desire.

Of course if you do erase the chip, the only way to restore your board would be to desolder the erased chip and solder a pre-programmed chip in its place.

Thank you for this information Paul.
As I said on an other post, I won't use the Arduino IDE/libraries, so it is unlikely that I want to restore the stock firmware. I just want to use the KL02 as a voltage monitor/boot IC.
About that, could you tell me what is the purpose of the B0_13 pin in the boot process?
Thank you.

EDIT: I just saw the Bootloader chip page, that is what I was looking for, great!

Is there any chance that the hardware initialization has not been done when we receive the board? i.e. as long as the board is not powered on the HW_OCOTP_CFG5 fuse word is blank.

EDIT2: Ok, I read on an other thread that the i.MX RT fuses are set in factory.
 
Last edited:
Is there any chance that the hardware initialization has not been done when we receive the board?

We have multiple processes and double checks (including daily inventory reconciliation) at PJRC which are designed to make the odds of such a terrible mistake virtually zero. In the roughly 12 years we've been making Teensy, I can not recall even 1 case where this has ever happened. Plenty of other things have occasionally gone wrong, like shipping the wrong board, packages run over by a postal truck, issues with credit card processing, etc, etc... but failing to test & program boards isn't one of them.

When you first apply power to any brand new Teensy, the orange LED is supposed to blink. The LED blink program is loaded into the flash memory via a USB cable using the normal bootloader-based programming process. Every Teensy goes through this test and can not pass unless all prior tests were completed successfully. Long ago the pass/fail was confirmed by a human watching the LED. We still do that, but the test fixture also measures the USB cable current and watches for it to change by about 2-3 mA as the LED turns on, so the test can't pass unless the LED really is using the right amount of power. Our testing process also keep a count of the number of unique boards it has passed in each session, which is shows on a bright 7-segment display the operator can see while testing the boards. The counter doesn't increment if any part of the test fails. That number is checked against the total, and as the boards are tested and placed on an anti-static mat, they are arranged in little groups of 5 boards, and areas of 25, where there's a strong human tendency to confirm the 7 segment display number is a multiple of 5 and 25 as each row of 5 and group of 5 rows is completed. We also have a process for logging each failure, which keeps the small number of bad boards from being able to get mixed up with good ones (and gives us a sure way to reconcile inventory to catch any mistakes). Human error is always still possible, but I can tell you we've put a lot of work into the process over the years to really minimize the odds of a mistake not getting caught.

Slow blinking on the orange LED is a sure sign your board was properly initialized and fully tested. Likewise, holding the button of ~15 seconds for the blink restore process is also a sure sign everything on a Teensy 4.0 or 4.1 was properly initialized.

Hypothetically speaking, if a board isn't initialized, you would also not see 3.3V on the Program pin (when not pressing the pushbutton) because the pin is 3.3V due to the internal pullup resistor inside the MKL02 chip. Pressing the button would not cause the red LED to turn on. The IMXRT's DCDC converter would also never turn on to create the 1.15-1.25V power for the CPU, since the DCDC_PSWITCH control signal is held low by a 100K pulldown resistor and can't turn on without the MKL02 driving that pin high.
 
Paul,

my remark had nothing to do with PJRC quality control, sorry if my sentence was not clear.
I just wondered if the MCU could arrive blank and programmed at the first boot by the bootloader chip, so that I could enable SWD (of iMXRT) by disabling the KL02.

But, as I said in my "edit", it is not the case because the RT fuses are set at factory.
 
Here is my attempt at this idea. I decided to bring out all MKL02 pins to a header, and add two standard Cortex jtag headers (one for the RT1062 and one for the MKL02/SWD). The flex PCB just got ordered at OshPark, so we will wait and see. I am not sure the solder points for the Teensy 4.1 board connection are going to work for soldering. I just couldn't figure out a way to get Eagle to do what I wanted. You can use jumpers across the 2 16 pin headers to indivually attach/detach pins from the bootloader chip to the board, if all are attached, the bootloader chip is fully connected and acts like a standard Teensy. Another jumper allows to you completely hold the bootloader chip in reset, so essentially you could connect a different MCU. Also, the TRST pin can be used to control the DC/DC converter on the iMX, as it needs a rising edge to turn on.

Screenshot_1.png
 
Last edited:
You might want to radius/chamfer the internal angles on that flatflex so they are more resistant to tearing, and the stress isn't quite
so close to the traces.
 
Here is my attempt at this idea. I decided to bring out all MKL02 pins to a header, and add two standard Cortex jtag headers (one for the RT1062 and one for the MKL02/SWD). The flex PCB just got ordered at OshPark, so we will wait and see. I am not sure the solder points for the Teensy 4.1 board connection are going to work for soldering. I just couldn't figure out a way to get Eagle to do what I wanted. You can use jumpers across the 2 16 pin headers to indivually attach/detach pins from the bootloader chip to the board, if all are attached, the bootloader chip is fully connected and acts like a standard Teensy. Another jumper allows to you completely hold the bootloader chip in reset, so essentially you could connect a different MCU. Also, the TRST pin can be used to control the DC/DC converter on the iMX, as it needs a rising edge to turn on.

Nice to see someone else giving this a shot. I have come a long way since my last post, I will share here shortly. One of the issues I had was that the pads were so close together there wasn't much room for the holes and copper. I was able to get it to work once but later attempts caused the pads to lift off the flex pcb. I thought about using low temp solder but I went another route instead. Let me know if yours works out.
 
I will. Still waiting on OSHPark. I am guessing another week or more. I have my 'sacrificial' Teensy ready to go when they arrive. I was hoping if this initial run works out (and, no, I don't expect the first run of anything to work). I was hoping Paul could give us some measurements from his Gerbers or board files so we could add a couple of through-hole pads where the pins on the teensy fall under. Then, we could solder those first, giving perfect alignment for the hard job of soldering, _and_ would provide a form of strain relief for the board while in use.
 
I tried to establish a J-Tag debug connection according to the work of Spencez. Good job on that! I really like the flex PCB!

I used a break out board fitting to the MKL02 chip. It was unsoldered from the teensy board, put on the break out board und reconnected to the teensy pcb.

So far I can program the teensy board by the original teensy loader and the usb serial port appears and reports the the board is still running. Nothing damaged.

But: I am not able to establish a J-Tag connection.
jlink-fail.PNG

I would really appreciate to have the schematics of the flex pcb to match my wiring against it. Would you like to share it?

Do I miss something else? Do I need some Pull-ups/downs like I have seen on some evaluation/example schematics? As far as I can see on the pictures there are none added. I can see, that the MKL02 is still in place, but I cannot spot what is connected to the J-TAG and what to the teensy (and what is disconnected).
 
I would really appreciate to have the schematics of the flex pcb to match my wiring against it. Would you like to share it?

Do I miss something else? Do I need some Pull-ups/downs like I have seen on some evaluation/example schematics? As far as I can see on the pictures there are none added. I can see, that the MKL02 is still in place, but I cannot spot what is connected to the J-TAG and what to the teensy (and what is disconnected).

You should be able to establish a J-Tag connection as long as you connect everything between the Teensy and the MKL02 except TDO, TCK, TMS, TDI. Pins 6, 8, 5, 7 respectively and connect those along with a ground and vref to your debugger. The MKL02 can not be connected to the J-TAG pins at the same time as the debugger. Here is the original schematic I used. I would connect my debugger to the pins stated above as well as bridge the MOD pin to GND (if not connected to the MKL02)
https://i.imgur.com/OyeJqOo.png

Although I did move away from reusing the MKL02 because a newer chip I received from Paul had new software which would cause it to blink the led when J-Tag was not responding and I could not get it to work correctly anymore. Diagnostic Blink Codes for reference. https://www.pjrc.com/store/ic_mkl02_t4.html
As long as you do not see the two blink code, I do not think this will be an issue for you.
 
Thank you very much for your reply and the schematics!

I do not see any blinking. I can detach the JTAG connection from the MKL02 with jumpers. And I can program the teensy board with set jumpers.

So far, so good. When I find the time I will double check all connections. There are those "flying" wires like you have on your second picture. After function check with the teensy loader secured with hot glue. So I think it might be the connection from breakout board to the JTAG connector and/or a missing "MOD pin to GND".

At least some Test-Pads for the JTAG and 0 ohm resistors to detach the MKL02 would be a charm for future boards :)
 
Will there come a Teensy 4.x that does have the hardware debugging pins?
Is the 4.0/4.1 deliberately designed such that it is not possibly to hardware debug or what is the reason, i mean everybody wants this or not ...?
Could the NXP development board used right out of the box for debugging normal Teensy 4 sketches?
 
Will there come a Teensy 4.x that does have the hardware debugging pins?

Can someone make a clear statement on this point?

I work for a measurement device prototyping department in a big company (top 100 ww) and we are looking for a prototyping board that easily works with arduino AND with professional IDEs that support debugging. We would take hundreds of devices annually, but except nucleo from STM, we couldn't find a board that fits our needs.
 
Yes, I would like to know that too. I do not understand why the teensy doesnt have jtag pins.

Have you read this thread from the beginning? It seems the JTAG pins are at least partially used by the bootloader chip. I'm not sure, but I think the bootloader chip uses the JTAG pins to erase/program the main processor.
 
Can someone make a clear statement on this point?

I work for a measurement device prototyping department in a big company (top 100 ww) and we are looking for a prototyping board that easily works with arduino AND with professional IDEs that support debugging. We would take hundreds of devices annually, but except nucleo from STM, we couldn't find a board that fits our needs.

You can use Microsoft's Visual Studio with Visual Micro to Program and debug everything that is programmable with the Arduino IDE.
Id DOES NOT use the Arduino IDE.
For Teensy debugging is done using the UART Serial ports.
EDIT: Also see here for additional debugging info.
 
I saw that people made mods that place the chip outside and so acces the required pins. I guess if they can do it, prjc can also change the design to make it accessible for everyone.
 
If the JTAG connections from the processor to the programmer controller would be connected via 0ohm resistors then the connection could be easily detached and reattached to a JTAG header (in conjunction with jumpers to reenable to programmer controller). Some LPCexpresso boards used to have such connections. It will make the board a little bit bigger for sure.

It would be even cooler if the programming controller would provide a debugging feature itself like other boards like the (old) LPCexpresso boards or the stmDiscovery boards. To be faire I have no idea how much effort this would be but I would pay for a "premium" dev version since this would reduce developement time on the other hand.

There exist eval boards with the same processor and JTAG connectors, but they could not be ordered at the moment (+26 weeks). A baseboard that provides Ethernet, CAN and a debug header would be a great thing.

Well and its a long time till Christmas with all that wishes ;)
 
Back
Top