Debugging strategies

BeinerF

Member
Hi,

this is a very basic question and I hope that experienced developers here are not offended :) .

I am always wondering what kind of debugging strategies other people use when developing with(for) teensy.

I am more or less limited to some simple tracing strategies like
  • using the on-board-led or a bunch of additional LEDs and then get them to do something at relevant locations in my code
  • using Serial.print(ln)() at places of interest

Their must be more.

Any additional recommendations from experienced teensy-developers would be much appreciated.
 
You hit the two main ones, when you don't easily have a hardware debugger available.

That is doing digitalWrites to different pins and Serial.print of additional information.

To augment this I often use a Logic Analyzer, which I can use to follow those digitalWrites that happened and also to see exactly what things are being sent out using different protocols like SPI, or I2C or....
 
Someday it is hoped that Paul will get enough time to rework the MLK02/MLK04 bootloader to enable the debugger traces that are on the 3.5 and 3.6. Then you would be able to hook up GDB or a similar debugger. But so far, that hasn't happened.

I'm an old enough programmer that I learned on punched cards, and debugging via batch tracing is still one of my main goto methods.
 
Serial.println() kid here. I put them in strategic places in the code or libraries and use them to narrow down the problem. Has thus far always worked for me. For peripherals, mostly communication stuff, I have a Tektronix scope that can analyse serial protocols, but there are cheaper and equally powerful USB scope/analysers available from Sparkfun or Adafruit.

I think SWD or GDB would be a useful tool for power users, but kinda lost to the majority of Teensy users which use the Arduino IDE (which afaik has no such debug support).
 
Thanks guys for the comments.

I am glad that I have not missed something really obvious.
And yes KurtE, I actually forgot to mention that I have also a small Saleae logic analyzer in my tool box, which should probably be used more often.
I am actually teaching a very basic Embedded Systems Intro Course using Teensy 3.2, however with myself having a strong "Jack of all trades" mechatronics background,
I am always keen to here the opinion of some 24/7 coders :).

Thanks again
 
Last edited:
You hit the two main ones, when you don't easily have a hardware debugger available.

That is doing digitalWrites to different pins and Serial.print of additional information.

To augment this I often use a Logic Analyzer, which I can use to follow those digitalWrites that happened and also to see exactly what things are being sent out using different protocols like SPI, or I2C or....

When developing/testing time critical code this is exactly what I'm doing also: Look with LA the different digital pins that are driven say by ISR, lengthy code segments etc. Serial.printf only seldom, as it is too slow and may interfere with main code.
 
This will be obvious to most people, but for those starting out (like me) my elaboration on Serial.print technique is to set up a counter that increments at a particular function, and then send its value to serial print at a known interval such as one second. This is useful when something is happening at a fast rate and can highlight when code is taking too long to cycle.
For example I have used this on Can Bus when I expect to see 7500 new messages per second. When my counter drops to a value less than expected, I know I have a problem with my code and/or hardware.

Darcy.
 
Mmmmmmm...kcachegrind/valgrind, anyone?

Serial.println() kid here. I put them in strategic places in the code or libraries and use them to narrow down the problem. Has thus far always worked for me. For peripherals, mostly communication stuff, I have a Tektronix scope that can analyse serial protocols, but there are cheaper and equally powerful USB scope/analysers available from Sparkfun or Adafruit.

I think SWD or GDB would be a useful tool for power users, but kinda lost to the majority of Teensy users which use the Arduino IDE (which afaik has no such debug support).

I've had good luck over the years troubleshooting with kcachegrind/valgrind (I love the visualizations!) and I was trying to figure out how to do that on Teensy; I have a large, complicated project in hand at the moment, and I could really use the visualizations. I couldn't really figure out how to do it though. I've never used the debug pins, and it sounds like they're not brought out anyway. But if someone could tell me how to use my favorite tools one again I think I'd be so happy I'd cry...

You also know that the moment some dev finds out how to show someone's code stats like in the image below, that dev is going to be God in the eyes of Arduino/Feather/Teensy developers all over the entire world...you KNOW it...

KcgShot3Large.gif
 
I am half a month with Teensy and embedded programming.
(I have lots of programming experience in other areas though. And some basic electronics knowledge.).

Just today I've managed to configure Eclipse for Teensy. Blink and MultiSerial work!
It has appeared that with new Eclipse-Neon it is not difficult at all. Articles about configuring Eclipse at PJRC are quite outdated and overly complex. Sorry I am not describing the process here, it should be a separate topic.

Next step will be to configure a debugger.
I see on back of my Teensy 3.5 there are three contacts for some debugger hardware.
I am reading about SWD and JTAG. Have no experience with this stuff...

Could somebody give a hint what to read about what to connect to Teensy do debug programs in Eclipse?

Thanks!
 
well, it does not sound promising.:(

But what about this?
http://hackaday.com/2016/08/17/introducing-the-teensy-3-5-and-3-6/
Paul Stoffregen says:
August 17, 2016 at 12:02 pm

For these new Teensy boards, I added a provision to use the debug signals. See the comments and bottom-side photo on the Kickstarter page. There’s a pin you pull low to tell the bootloader chip to tri-state those signals. Drive that pin high or just disconnect (it has a weak pullup) to return to Teensy’s normal mode.

Also here https://www.kickstarter.com/projects/paulstoffregen/teensy-35-and-36/comments?cursor=14226679
Paul Stoffregen 2-time creator on August 17
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.
So, it looks like it is doable.
Did someone try?
 
Last edited:
It is up to Paul to do and publish the change for supportable general use. Those quotes are same day about capability - there are others since noting it is a scheduling issue on Paul's time and somewhat on any pending Arduino core debug support.

From here pjrc.com/store/ic_mkl02.html is this:
Future Debug Enable
Future versions will support a debug request, using the PTA3 signal. When this signal is unconnected or HIGH, the chip will function normally. When PTA3 is pulled low, future versions will tri-state all signals connected to the MK20 chip, and will ignore the Program signal.
This future feature is intended to allow connecting a debug adaptor, where the cable would short PTA3 to ground. When the cable is plugged in, the MKL02/04 will effectively disconnect from all signals and allow the external debug cable full access.
Support for this debug request signal is planned for mid-2016. If you design a PCB now with a debug connector, the PTA3 signal should be connected to a pin on the debug port which the debug cable shorts to ground.
 
>Support for this debug request signal is planned for mid-2016.

Now it is quarter of 2017. I see in schematics and on the Teensy 3.5 board itself the contacts for debugging.
Are you saying the debug feature is not yet announced/supported, or it is not implemented yet in MKL02/04 ?
 
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.
 
Thank you Paul!

PS/ If there would be a debugger, may be it would simplify/accelerate development of USB host library and other projects ;)
I do not know much about embedded programming but in regular programming a debugger helps greatly.
 
I highly doubt Paul got where he is from raw chips to multiple working Teensy's without have a full debug system setup. Others have hacked debug onto the prior T_3's and the first T_3.6 had those pads exposed and he controls the bootloader chip. He'd have to have a test system. The problem is making it 'user supportable' without any compromise to system function as PJRC defines it. However he has great external tools too and a generally stable system to work on like all the other folks doing device coding here on the forum.
 
Quick question on this subject (to Paul, hopefully).

I understand that the longer term plan for the Teensy bootloader is that holding the DE pin low would tell the bootloader to leave DC and DD alone for an external debugger's use.

Does the current bootloader take immediate control of those pins and drive them immediately? Or does it leave them high impedance until a sketch needs downloading?

If I wanted to use an external debugger right now (Teensy3.5) am I safe to connect straight to the SWD pins, or should I erase the Teensy bootloader chip first?
 
Thanks Paul, so erasing it would be the safest solution?

I'm about to port a longer term project from FRDM-K64F to teensy 3.5 but need to retain proper debug capability. Just don't want to blow anything up.
 
Corrected::
Paul got where he is from raw chips to multiple working Teensy's without have a full debug system setup

Actually, I did indeed do exactly that.

But for the USB stuff, I have used a Beagle USB protocol analyzer from Total Phase. They were blue when I bought mine. ;)

... get the best answers when saying something WRONG - Now I know. That makes the second part all the more true . . .
... However he has great external tools too and a generally stable system to work on like all the other folks doing device coding here on the forum.
 
Hi,

New user here. My Teensy stuff should arrive tomorrow.

Some more advanced debug methods I have used are:

Data logging. Capture a bunch of data in an array and print it out when the dust settles.

A software scope: Set up some variable assignments in the function you are debugging for example - probe1 = value1; probe2 = clock2; As may probes as you want although 4 may be a good number to fit on your graphics screen.
Then in a timer interrupt the probe values are saved to arrays. The time base of the scope would correspond to the interrupt period. When the arrays are full, you display the waveforms on your screen with some scaling of the numbers so it fits. I have used this method fairly recently for looking at the internals of a psk31 receive routine. Although my scope implementation was crude, it was a lot better than just guessing at what was happening.

Ron
 
Is you have a USB connection to a PC or tablet you can spew out periodic data values of import. Of course LED's are easy if somewhat binary. Without USB you could do Serial [1 or 2] with GND and two pins to a second Teensy that does have USB connect. Or put a display on the device and shows state or values as needed.

Not indicated what devices etc will already be in use and what is being controlled - but Scope or logic analyzer can be complemented by other open bus noted above to get a good picture of what is going on where - ideally without getting in the way of the task at hand. Should be other threads with more details depending on which way works.
 
Back
Top