Debugging strategies

I am curious what batch tracing is...

Batch tracing is just print statements. On the Teensy, it would be connected to the USB stream, which you can scroll back.

It is how we debugged things in my high school and early college days when I programmed the computer with a deck of Hollerith punch cards (or punched paper tape), that you gave to the attendant and some time later a ream of printer paper output along with your cards/tape would appear in your output basket. A lot of those runs were overnight (the owner of the computer would use it for the normal business during the day, but at night they would do some runs from the local school), so you only had one shot a day to do the programming.

Lets see, my first High School I programmed in Fortran (Fortran 66), at the other High School after we moved, it was Cobol. At college, Pascal was used (it was a pain doing all of the special characters on the 026 card punch which did not have characters like ';'), and other languages (CDC 6600 assembly, Snobol, and I don't remember what else). Eventually they got terminals hooked up to the computer (both 110 baud teletypes and those fast 300 baud CRTs), and cards faded away. Towards the end, I got to play with the UNIX (v6) system and its directly connected console.

On each of the GCC ports I've worked on, I tend to put in various undocumented debug options that spit out a lot of output, and then I can use grep or custom perl scripts to look for what I want. Yeah, I use gdb as well, but a lot of times, bugs occur as a result of various complex interactions, and it is simpler to just let it run, and sift through it later.
 
Last edited:
The good old days ;)

My High School had a hand me down IBM 1620 where I learned Fortran 2... I also took after school class (twice a week) at Rockwell International where I learned PL1... Sometimes you punched your own cards, other times you filled in coding sheets and they had a key punch operator punch up the deck for you... You then needed to carefully check over your cards and make any editing changes you needed (read that is punch new cards) and then submit the job, which you would get the results back the following class...

I also appreciated it when I went to college and had better card punches (ones that you could hit backspace and make a correction...) and then teletypes and CRTs...
 
So not a typo - but similar documenting the execution path for offline debugging.

I didn't start until I got my own BASIC computer in high school - then got the fun of punch cards from a remote campus at college with COBOL and FORTRAN to start before remote terminals went live ... funny then I went to the main campus and it was back to punch cards for a time . . . . even the terminals of course were batch time.
 
IMO, every serious developer should learn to use a debugger - it really does fix bugs faster. On the other hand, print() and pin outputs are more universal/generic and eventually work.
 
Hi,

Debugging the Teensy 3.5/3.6 is quite easy actually. Just solder a thin wire to pin 15 of the KL02Z (reset pin) and tie it to VSS (hold the KL02Z in reset) to release the debug port.
Could do the same for 3.0/1/2 I think, but the debug pins are not easily accessible.
 
Last edited:
Indeed, I tried that this morning, it works great. :) I used a other compiler than the one with Teensyduino because gdb-py is not "shipped" with it, and my IDE needs it for debugging, but that shouldn't matter.
 
Works for me too.

Indeed, I tried that this morning, it works great. :) I used a other compiler than the one with Teensyduino because gdb-py is not "shipped" with it, and my IDE needs it for debugging, but that shouldn't matter.

I've wired to pin 15 of the MKL02 and pulled it to ground, allowing connection of the Segger J-Link.

I've been using Segger's embOS and other libraries for the last year or more for professional development, so I set up a Segger Embedded Studio project for Teensyduino that allows Arduino-compatible project management, compilation, and full hardware debugging. It is so much faster to develop compared to Arduino IDE!
NOTE: For those that are doing this hobby-only you can use Segger's Embedded Studio for free (full version) along with their J-Link EDU (which is about £55+VAT).

If only the DE pin on Teensy 3.6 was just wired to the MKL02's reset pin we'd be sorted without any updates to Paul's firmware!

Just trying to finish off the documentation for the project template and hardware-hack guide... then all can benefit ;-)

Matt
 
Great :) I agree, if the DE pin was just the reset pin it would be much easier!

One thing to notice, be very careful after soldering a wire to that pin 15, breaking the PCB pad is very easy to do, and good luck re-soldering it after that... I tried, no success! Put a glue spot to secure it in place.

Another idea for a low-cost debugger : CMSIS-DAP with a Teensy 3.x (or even a pro micro) https://github.com/myelin/arduino-cmsis-dap
 
Does this: https://www.segger.com/products/debug-probes/j-link/models/j-link-edu-mini/ work for Teensy 3x? It says it works with all Cortex M cpu's and is only $18 US (non-commercial use, however).

BTW: Having Arduino compatibiliity and a h/w debugger w/o the Arduino "IDE" would be fantastic. Looking forward to Matt's guide.
I'm sure the J-Link Mini will work just fine. We've tried the J-Link EDU, and I use the J-Link Pro every day. You'll get higher speeds as you go up, but the mini is limited to 4MHz - which will be just fine for Teensy work.

I'm sketching out some articles here: https://medium.com/@mattmatic/ but will probably put the meat of it in a thread on this forum too :)
It'll be best if I drip-feed the info rather than one big post (otherwise I might never finish!)
Just to tempt you: the speed of compilation and debugging is unbelievable in comparison to Arduino-IDE :D
 
Last edited:
Nice article :)

The same thing can be done for the 3.2 as well, just without nice big pads for the debug pins... but 2 more thin wires to solder :p
And for the 3.0/3.1 it's the same principle, it should work too.

On my part I use Qt Creator for the IDE, with some neat config stuff in QBS. I released a "howto" some time ago (ArduinoQbs), [but unfortunately it's broken with the latest version of QBS, I need to fix that] FIXED! :).
 
Last edited:
Thanks BBenj.


Just a general thought about JLink Mini - the connector is 0.05” pitch, not the easy to use 0.1”. It’s very fine pitch for hobbyist work. So you may need an adapter (eg Olimix ARM-JTAG-20-10 ) to bring it back to something larger. The JLink EDU standard size will allow DuPont connectors etc (like my images).
 
Hi MattMatic and BBenj,

Thanks for your work on connecting a debug probe to the Teensy 3.6. I started a new thread:

https://forum.pjrc.com/threads/4882...g-probe-amp-0-MCUXpresso-IDE-with-GCC-GDB-etc

pointing to an NXP MCUXpress forum question I asked, where it turns out that MCUXpress can be used with the ~$20 LPC-Link3 debug probe to debug and trace the Teensy 3.6, modified as you suggest:

https://community.nxp.com/thread/466997

BBenj wrote: "DE pin was just the reset pin it would be much easier!". I think this can be done with some conductive epoxy and a single strand of fine copper wire between KL02Z pins 15 and 3. Alternatively it would be possible to solder to pin 15 and then to the track between pin 3 and the DE pad, rather than try soldering to two little pins, pads or whatever of the KL02Z.

I also suggest that the JTAG_TDO/TRACE_SWO, for Serial Wire Viewer (SWV) transfer of data in real-time back to the IDE, via the debug probe, can be exposed by soldering to a via which is on the track to KL02Z pin 9.
 
No chances unfortunately, you have to hold the KL02Z in reset or it will interfere. You might be able to go away with shorting pins 14 to 16 together for a bigger solder blob, but check first that pins 14 and 16 are not connected anywhere (or outputting something)! (Doesn't seems like it in the schematic, but the extra "lines" in it for theses 2 pins are curious.)

Pads DD/DC/DE should allow
bypassing the KL02Z, but AFAIK it's not yet implemented on the firmware.
 
While I think that conductive epoxy is probably a good way of connecting to pin 15 of the KL02Z, here is how I soldered to it. This requires a stereo zoom microscope, but does not place extreme constraints on the soldering iron tip or how it is manually positioned.

Ordinary soldering technique - placing the iron on the pad - would surely melt all the pads of the KL02Z within a second or so.

I got one wire from a 1.27mm pitch rainbow ribbon cable, for IDC connectors, and cut off all but one of its copper strands. I used hot-melt glue to mount it, via its insulated part, to the Teensy 3.6 PCB - see the image. Then I trimmed the strand to about the right length and tinned it with some fresh tin-lead solder. Then I bent the strand into the correct position, with it being pushed downwards onto the solder blob of the pad. I did this with tweezers and with a scalpel slightly lifting the end of the insulated part of the wire, so when I released the scalpel, it moved towards the PCB.

Then it was relatively easy to complete the solder joint purely by heat conducted through the strand. The soldering iron (Thermaltronics with M7CH178 tip) was free of excess solder. I touched it to the strand about 1.5mm above the pad, pressing the strand into the solder blob, which melted within a second or two. Even with this short heating period, pad 16 started to melt too.

Teensy-3.6-debug-reset-wiring.jpg

The theory is that the thin strand would be unable to conduct enough heat to raise the whole 16 pin package to solder melting temperature. Likewise it would conduct insufficiently to melt the insulation on the main body of the insulated wire.

It will be a while before I complete the project of hooking the Teensy up to the LPC-Link 2, which is an inexpensive debug adaptor which should work with MCUExpresso, and so with gcc and gdb. It uses a 1.27mm spacing 10 pin header. To connect to this I bought some matching pin strip with right-angle ends:

https://www.ebay.com.au/itm/222666001537

so I can solder 10 pins of this to a little piece of PCB material I already have, with 1.27mm tracks on the top. Then I will epoxy this to the memory card metal cover and wire it all up with wire-wrap wire or perhaps thin polyurethane insulated transformer wire.
 
Actually, the soldering iron contact point is 0.8mm or so above the PCB - just below where the strand bends to become vertical.

This photo is from just before I applied the iron.

Teensy-3.6-debug-reset-wiring-before-heating.jpg
 
It's *still* not implemented. Why a year late? Work on Teensy 3.5 & 3.6 (released October 2016) and the USB host library for 3.6 (first release March 2017) pushed that and many other project goals well into 2017.
So, we're about another year later now. I have this vexing FastLED problem to debug https://forum.pjrc.com/threads/5052...ion)-code-hangs-on-show()?p=172951#post172951 and Serial.print just doesn't look like it's going to be doing it :-/
I just bought a teensy 3.6 hoping it did have proper debugging options, until I realized that it didn't unless I start soldering it seems.
So, am I back to Serial.print and hope for now?
 
Last edited:
So, I've just verified the same behaviour with teensy 3.6, my code hangs on the first fastled.show() and if I send code that uses adafruit.neopixel.show() instead, that code works, and then allows my fastled.show() code to work afterwards when I flash it.
How can code from one sketch affect the next code I will flash next, and allow it to work?
Once the new code is on, it works forever, until I pull the power and reset it.
Is there some code or state that is set by the first program, somehow survives a reboot (but not power cycle) and allows the second code to work?
 
Back
Top