Teensy 4.0 - how to connect a jtag debugger ?

Yes, very interesting, I'll have to try it. Only I don't like Teensyduino, so I'll have to see if I can get it working with the MCUXpresso IDE.
 
Is it possible to reprogram the MKL02 on the Teensy 4.0? I would be interesting in making or porting some firmware for it that talks JTAG to the IMX, similar to what Segger does with their JLINK-OpenSDA firmwares for KLxx chips.
 
Hiya,

[edit: just noticed this was already suggested.. ;-) ]

Call me a spoiled brat but I insist on having a proper debugger for embedded work ;-) Life is too short for printf debugging complex issues on a chip with a gazillion peripherals.
So... I have a gig that I may want to use Teensy 4's for, and I'll probably just buy the NXP eval board - which most usefully breaks out JTAG - plus has the other stuff like ethernet/USB/etc (and CAN and.. all sorts of optional junk in the trunk). For $99 it's _well_ worth it to me as a development/debug platform. The resulting code I'll deploy on Teensy 4's of course.

NXP board:
https://www.nxp.com/design/developm...evk-i-mx-rt1060-evaluation-kit:MIMXRT1060-EVK

Schematic: (may need an NXP account, just sign up)
https://cache.nxp.com/secured/asset...f90b87aa77d3412e2931a337f61ebcc2&fileExt=.zip
 
Hiya,
Call me a spoiled brat but I insist on having a proper debugger for embedded work ;-)

Ok Spoiled Brat ;) :D

For me, it would be nice but not a have to. Besides if you need some source level debug support you can always try playing with the stuff from VisualMicro, especially now that @ftrias has setup a nice GDBStub setup, and Visual Micro put in some support for it, you can do some of the debugging using that.
 
Here's a few random bits of info which might help...
Attempting this plan won't be easy, but hopefully these tips can save you from the most frustrating issues which aren't well documented anywhere... other than this forum message! ;)

Thanks Paul for the details. It's however unfortunate that teensy 4 didn't make easy hardware debugging a priority when it was clear that there was interest in 3.x chips (but it was hard and out of reach for most).
From what I read so far, it seems that 4.x is no better and you can't just connect a debugger?
Unfortunately, most users will not have hardware debugging experience, so it would be good to have something that works easily with a howto (that someone else can write).

In the meantime: how about something simpler. ESP32 is overall a lesser chip compared to teensy 3.6, but I mostly switched to it because I didn't have the issue of the serial port disappearing on teensy (on ESP32, it's an ftdi, so no problems), but the biggest thing that helped me on ESP32 was that it traps CPU crashes and displays a helpful message, like division by zero or loading from a forbidden address (buffer overflow)
And the best part is that it displays the content of the stack, and a stack decoder gives you a full traceback in your code, so you know where things crashed.

This has saved me so much time. Honestly, this is a main reason why I've used ESP32 chips over teensy in the last years.

Teensy 4 is definitely a better chip, but it really needs better debugging. If easy hardware debugging is still mostly off limits for most, can you add what ESP32 has been doing for years now, and helps out in 95% of the cases?

Thanks, Marc
 
As far I know (I may be wrong) JTAG is disabled by default anyway, on I.MX.RT. , instead SWD is used. But this would work too.
Edit: No, the other way round. SWD is disabled on Teensy.

I think it's a problem to enable HW-Debugging and keep the bootloader internals secret?
Then, I think, faults for division by zero are disabled, too (but there is a bit to enable them)
A Stack trace is not possible without debugger. The ARM-ABI does not define where on the stack is the return address.
GCC -unwind-tables would help, perhaps, but I was unsuccessful to get it work (Linker errors). Likewise -mpoke-function-names. So, a trace is currently out of reach, too (I you find a way to use these both switches, it would be helpful)
But I found a good way to print hardfaults. Maybe I publish some code or a library for this, but the general interest seemed pretty low so far. It isn'nt that useful without a stacktrace, too.

Yes the ESP is - regarding to things like these - fun.

And beginners see a errormessage, at least - they know "oops, something was wrong" - not a silent crash like with Teensies where nobody knows what happened, and without the slightest hint what may have happened.

Not beginner friendly.

I hope there is *something* to solve that on Pauls TODO (and not with a low priority). I was begging many many years for at least a dedicated Error-LED :)

When the next Teensy with 2 cores comes, we NEED better debugging.
 
Last edited:
Just my 2 cents worth: I also faced problem that I needed a decent and FAST debugger for complex programs written for embedded systems (not only Teensy but STM32 too). Although I got debugger with STM32 I find it too slow to work with. So I ended up with hybrid approach. I try to isolate hardware-independent parts of my software and make them portable so I can code on Windows machine and compile and debug Windows target. To be able to write UIs and audio I use in-house developed software emulation of LCD (redirect to Windows GDI) and software emulation of audio-DMA I2s hardware (using ASIO drivers to audio card).
That way I am able to write and debug complex software in the comfort of Visual Studio IDE. And I only do final integration using PlatformIO IDE (instead of Arduino), STM32IDE or Embitz.
 
Hello,

needing an i.MX RT board with Ethernet in a small form factor, the teensy 4.1 got my attention.
However, I am not interested in the Arduino eco-system and I need a full access to the JTAG debug port (as SWD is permanently disabled by fuses).

So, I plan to re-program the KL02 chip to properly drive the PSWITCH, POR_B, JTAG_MOD and BOOT_MODE0 signals at boot and let the others in high-Z state to connect an external JTAG probe.

But, before to buy the board, I still have a couple of questions:

Does anybody know whether the KL02 is protected against a full erase or not?
What is the purpose of the B0_13 pin at boot?

Thank you!
 
Indeed, I missed this recent thread, thanks.

However, de-soldering the KL02 only makes sense if it can not be re-programmed. Even so, I would prefer to cut the PCB traces.
 
Hello all,

Debugging is the most fundamental aspect of microcontroller programming. If you can't single step source code, add breakpoints, view memory (RAM, EEPROM, and flash) and see internal MCU registers, you are not working smart. Serial.printf is not effective debugging, adding a live watch to a variable is debugging which is available by using a Segger J-Link SWD debugger. The Arduino IDE is probably the most difficult to use IDE, use Eclipse and you will see the difference.
 
Better than "fine enamel wire" is 30 gauge kynar insulated wire designed for wire wrapping (an ancient ritual almost forgotten). It can be stripped to expose a very short length of wire and with good technique the insulation won't deform.

*** I love that stuff. Have a good supply of it, left over from my wirewrap days. HOWEVER - looking at that boot chip - I think
even the 30-gauge stuff is too big.

Or is it? The boot chip is an MKL02Z32VFG4 CPU. It's a 16-pin QFN, and the lead pitch is .5mm. 30AWG wire is listed as .2546
mm in diameter. So about half the lead pitch.
 
Back
Top