Top Internet of Things Daily & Weekly

Modifying the Teensy 3.5 and 3.6 for ARM SWD Debugging

Modifying the Teensy 3.5 and 3.6 for ARM SWD Debugging  #IoT #Cloud #BigData

  • This article is about how to change the board to use it with any normal SWD debugging tool, e.g. Eclipse and the Segger J-Link.
  • For the Teensy 3.1, I have found a way to do this (see Hacking the Teensy V3.1 for SWD Debugging) and we used that for several Teensy boards.
  • The following picture shows the location of the debug signals on the bottom side of the Teensy 3.5 and 3.6:

    I added a 2×4 SMD pin header and a 1×5 pin row on the bottom side:

    I’m using a SEGGER J-Link to connect to the board.

  • Another simple, and easier, option is to add a pull-up to the header near the SD card:

    With this, the GND line to DE is not needed anymore and can be removed:

    And with this, the J-Link SWD protocol is able to take over the ARM Cortex-M4F:

    Finally, I can debug the Teensy with Eclipse, GDB, and standard SWD debug tools:

    The Teensy is a great board, and Paul Stoffregen does a really great job.

  • Because the DE (Debug Enable) signal does not work, it requires removal of the KL02Z microprocessor from the board.

The Teensy 3.5 and 3.6 require hardware changes in order to use debug tools like Eclipse and the J-Link. This guide walks you through the modification process.

@craigbrownphd: Modifying the Teensy 3.5 and 3.6 for ARM SWD Debugging #IoT #Cloud #BigData

Looking for a small, inexpensive ($25-30) ARM development board (say 120-180 MHz ARM Cortex-M4 with FPU, 512kB-1MB of FLASH and 256 KByte of RAM)? Then have a look at the Teensy 3.5 and Teensy 3.6 by PJRC/Paul Stoffregen:

The only problem? It is not possible to debug it. At least not in the traditional sense. This article is about how to change the board to use it with any normal SWD debugging tool, e.g. Eclipse and the Segger J-Link.

The tinyK20 we produced at the university for student projects are great: small, inexpensive, can be used for many projects, and can be both debugged with normal SWD debuggers, and can be even used as an SWD debug probe. However, with an NXP K20 (ARM Cortex-M4) running at 50 MHz, 128 KByte of FLASH, and 16 KByte of RAM, it is not the most powerful board. So something more powerful would be cool!

The tinyK20 has the option of a micro SD card on the bottom side. Maybe Paul had the same idea, and Hackaday produced an article back in August 2016 about two new boards: the Teensy 3.5 and 3.6. The Teensy boards are great (thanks, Paul!), but only if using Arduino libraries and the Arduino IDE, which never has been an option for me.

Instead, I want to use normal debugging tools like a J-Link. For the Teensy 3.1, I have found a way to do this (see Hacking the Teensy V3.1 for SWD Debugging) and we used that for several Teensy boards. But that wiring was not really easy, so we better used the tinyK20 as boards.

Now it seems that Paul finally has added an easier way to do SWD debugging (several asked for that in the forums/community).

And from the Kickstarter:

“You’ll be happy to hear those test point are on the bottom side. Look for the pads labeled “DD” and “DC”, for Debug Data and Debug Clock. There’s not a lot of room on the bottom side, so had to abbreviate. You might also notice the “DE” pin, for Debug Enable. This pin as a weak pullup. The idea is you pull it low to tell the MKL02 chip to tri-state the debug pins, so you can control them with whatever debug adaptor you use. Just disconnect or drive the pin high to return the Teensy to its normal functionality.”

Well, that sounds great!

Below are the schematics of the Teensy 3.5/3.6 from https://www.pjrc.com/teensy/schematic.html:

An NXP Kinetis KL02Z acts as the onboard interface and bootloader between the Arduino IDE and the ARM Cortex-M4F on the board. I have marked the relevant signals for debugging below (3.3V sense, Reset, GND, DD (Debug Data), and DC (Debug Clock)). The DE (Debug Enable) is close to G (GND):

So all that I have to do is to connect DE and G and I should be able to debug it, right?

I need:

The following picture shows the location of the debug signals on the bottom side of the Teensy 3.5 and 3.6:

I added a 2×4 SMD pin header and a 1×5 pin row on the bottom side:

I’m using a SEGGER J-Link to connect to the board. The Segger J-Link has the advantage that I can easily connect the signals. The pin out is available on https://www.segger.com/interface-description.html:

Below are the connected the signals to the Segger J-Link:

So I tried it out, and I was not able to connect to the board. Looking at the signals, it was clear that despite pulling the DE signal low, the Kinetis KL02 keeps sending  something to the K64F, making it impossible to take over with the J-Link:

It turned out that pulling down the DE signal is still not supported, from https://forum.pjrc.com/threads/42728-Debugging-strategies from 04-24-2017:

So what now? Wait again maybe a year or forever? Luckily, I have found a way, but it is the ‘hard’ way.

Pulling the reset line LOW to keep the KL02Z in reset does not work, as the reset line is shared between the KL02Z and the MK66F/MK64F. As the KL02Z on the board is not of any use for me anyway, the decision was to remove it from the board.

Removing the KL02Z from the board is a bit tricky, so we’re going to go through how Christian Di Battista (thanks!) helped me get the hardware modification done.

Use something heat resistive and place the board on it:

To get the device off more easily, use Flux Gel:

Apply the Flux Gel on the pins around the KL02Z:

Video:

Use a hot air station or anything suitable:

Then heat up the KL02Z until it can be removed. Because it has a bottom ground plate, it might take a while until it can be removed.

Video of the process:

With the KL02Z removed:

There is only one thing missing: The reset line needs now a pull-up to 3.3V. One option would be to add an SMD pull-up resistor (e.g. 4.7K) somewhere on that KL02Z footprint. Another simple, and easier, option is to add a pull-up to the header near the SD card:

With this, the GND line to DE is not needed anymore and can be removed:

And with this, the J-Link SWD protocol is able to take over the ARM Cortex-M4F:

Finally, I can debug the Teensy with Eclipse, GDB, and standard SWD debug tools:

The Teensy is a great board, and Paul Stoffregen does a really great job. But I really don’t understand why he makes it so hard to use his boards for debugging? Maybe others are used to printf() style debugging as a hobby, but to me, this is not the adequate way to develop for an ARM Cortex-M.

To use normal SWD debugging tools with the Teensy 3.5 and 3.6, it requires a hardware change. Because the DE (Debug Enable) signal does not work, it requires removal of the KL02Z microprocessor from the board. And because the board does not allow the standard SWD debug header, I have to create a custom cable. It works fine, but it is not ideal. I really wish Paul would have provided a normal 2×5 SWD debug header or footprint (ideally on the top side). That would make his boards even more useful.

Modifying the Teensy 3.5 and 3.6 for ARM SWD Debugging