Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 3 1 2 3 LastLast
Results 1 to 25 of 60

Thread: Debugging strategies

  1. #1
    Junior Member
    Join Date
    Nov 2016
    Location
    New Zealand
    Posts
    9

    Debugging strategies

    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.

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,653
    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....

  3. #3
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,785
    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.

  4. #4
    Senior Member Epyon's Avatar
    Join Date
    Apr 2013
    Location
    Belgium
    Posts
    443
    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).

  5. #5
    Junior Member
    Join Date
    Nov 2016
    Location
    New Zealand
    Posts
    9
    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 by BeinerF; 03-18-2017 at 08:18 PM.

  6. #6
    Senior Member
    Join Date
    Jul 2014
    Posts
    1,878
    Quote Originally Posted by KurtE View Post
    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.

  7. #7
    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.

  8. #8

    Mmmmmmm...kcachegrind/valgrind, anyone?

    Quote Originally Posted by Epyon View Post
    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...

    Click image for larger version. 

Name:	KcgShot3Large.gif 
Views:	427 
Size:	123.5 KB 
ID:	10090

  9. #9
    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!

  10. #10
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,848
    Quote Originally Posted by mm7 View Post
    ...
    Could somebody give a hint what to read about what to connect to Teensy do debug programs in Eclipse?
    See post #3 this thread - and similar notes - those debug pins are still 'future use'

  11. #11
    well, it does not sound promising.

    But what about this?
    http://hackaday.com/2016/08/17/intro...y-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...ursor=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 by mm7; 04-24-2017 at 12:34 PM.

  12. #12
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,848
    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.

  13. #13
    >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 ?

  14. #14
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,338
    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.

  15. #15
    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.

  16. #16
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,848
    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.

  17. #17
    Member
    Join Date
    Oct 2016
    Location
    Colchester, Essex, UK
    Posts
    55
    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?

  18. #18
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,338
    Quote Originally Posted by mundungus View Post
    Does the current bootloader take immediate control of those pins and drive them immediately?
    Yes, it does.

  19. #19
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,338
    Quote Originally Posted by defragster View Post
    I highly doubt 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.
    Last edited by PaulStoffregen; 04-29-2017 at 08:13 PM.

  20. #20
    Member
    Join Date
    Oct 2016
    Location
    Colchester, Essex, UK
    Posts
    55
    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.

  21. #21
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,848
    Corrected::
    Quote Originally Posted by defragster View Post
    Paul got where he is from raw chips to multiple working Teensy's without have a full debug system setup
    Quote Originally Posted by PaulStoffregen View Post
    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 . . .
    Quote Originally Posted by defragster View Post
    ... 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.

  22. #22
    Senior Member
    Join Date
    May 2017
    Posts
    141
    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

  23. #23
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,848
    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.

  24. #24
    Member
    Join Date
    Jul 2015
    Location
    Ontario, Canada
    Posts
    66
    and debugging via batch tracing is still one of my main goto methods.
    I am curious what batch tracing is...

  25. #25
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,848
    I'm going with a typo: Branch_trace

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •