Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 44 of 44

Thread: Debugging strategies

  1. #26
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,573
    Quote Originally Posted by Jake View Post
    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 by MichaelMeissner; 05-24-2017 at 02:52 AM.

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

  3. #28
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    5,177
    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.

  4. #29
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    237
    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.

  5. #30
    I find the debugging feature of VisualMicro useful for simple debugging.

    http://www.visualmicro.com/page/User...Explained.html

    I also like the Embedded Artists LabTool, but I don't know how it compares to the Saleae mentioned above.

  6. #31
    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 by BBenj; 09-11-2017 at 11:04 AM.

  7. #32
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    237
    Have you done it?

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

  9. #34
    Junior Member
    Join Date
    Oct 2017
    Location
    UK
    Posts
    8

    Works for me too.

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

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

  11. #36
    Member
    Join Date
    Nov 2015
    Location
    colorado
    Posts
    32
    Does this: https://www.segger.com/products/debu...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.

  12. #37
    Junior Member
    Join Date
    Oct 2017
    Location
    UK
    Posts
    8
    Quote Originally Posted by dgranger View Post
    Does this: https://www.segger.com/products/debu...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
    Last edited by MattMatic; 10-31-2017 at 01:41 AM.

  13. #38
    Junior Member
    Join Date
    Oct 2017
    Location
    UK
    Posts
    8
    Have thrown together the hardware prep side of the SWD/J-Link/Teensy 3.6.
    https://medium.com/@mattmatic/prepar...d-b014b0ce2999

    Let me know if it helps!

  14. #39
    Junior Member
    Join Date
    Oct 2017
    Location
    UK
    Posts
    8

  15. #40
    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 by BBenj; 11-14-2017 at 05:38 PM. Reason: Info update

  16. #41
    Junior Member
    Join Date
    Oct 2017
    Location
    UK
    Posts
    8
    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).

  17. #42
    Junior Member
    Join Date
    Sep 2017
    Location
    Bay Area, USA
    Posts
    14
    Hi, did you ever get Teensy debugging via Eclipse & GDB to work? I'm trying to get that to work now.

  18. #43
    Hi,

    Never tried, but mcuoneclipse.com seems to have great articles on that : https://mcuoneclipse.com/2017/04/29/...swd-debugging/ (but their website is not loading for me ATM, hope that will be fixed soon)

  19. #44
    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/48822...th-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.

Posting Permissions

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