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

Thread: Debugging strategies

  1. #51
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,911
    I would guess that maybe adafruit.neopixel.show maybe initialized something in hardware the that fastled did not

    If you reprogram it again after your fastled hangs, does the reprogram work? If so that could indicate somethings like maybe some startup timings are not working properly or... Been there. Although I have not done anything with fastled.

    As I have mentioned before my other strategy for debugging is to use Logic Analyzer. I use it to detect the state of the output going to the LEDS, also I often setup unused IO pins to either toggle or set high and low around pieces of code to help see where the code is going or hanging....

    Note: depending on Hang versus Reset... If I am using the Serial.print approach for debug,
    You might want to put in Serial.flush calls as well, as you might do a print and the next code line faults (example address a piece of memory associated with a device that the code has not enabled access to that portion of memory). When that happens any data sitting in the USB serial cache will not be output

  2. #52
    Thanks KurtE. Yes, I agree that something seems to be toggled in hardware, and seems to survive a reprogram but not a power cycle. That said, I've gotten that trick to only work twice on teensy3.6, which it works almost reliably on teensy 3.1 (doing the exact same steps). That's why I'm thinking about some hardware register or a bit of RAM surviving some reprograms but not all, and not a power cycle.
    As per your suggestion, I tried to wrap FastLED.show() with an LED toggle on top of serial.print, and indeed the LED gets turned on and not off while the program is hung in show(). I'll now have to do deeper debugging in the other lib, and it's not a fun one to work with :-/
    Good trick about Serial.flush(), I added that but it didn't help. It seems like Serial just gets killed by whatever makes fastled.show() so terribly slow

    Anyway, I'll continue further on https://forum.pjrc.com/threads/50526...951#post172951 I don't want to polute this thread.

    void show() {
    pinMode(13, OUTPUT);
    digitalWrite(13, HIGH);
    Serial.print("Show numpix ");
    Serial.flush();
    Serial.println(numpix);
    CFastLED::show();
    Serial.println("after show");
    Serial.flush();
    digitalWrite(13, LOW);
    };

  3. #53
    Quote Originally Posted by Robin Whittle View Post
    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.

    Attachment 13119

    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.

    Hi Robin,

    Did this pin 15 to ground work? I see other posts on the internet where they actually remove the KL02Z from the board.

    Many thanks for any help

    Andy

  4. #54
    Hi Andy,

    I haven't tested my arrangement since I have not had time to learn the NXP IDE, the debugger, this particular CPU etc. I will post a message here when I do.

    Removing the KL02Z might be easy, but it is right next to the BGA ARM CPU and I would be very wary of applying heat there. I want to retain it since I want to be able to use the Teensy boot loader in my final application, and it makes sense to test it with the same Teensy, rather than have to plug in another one with its KL02Z intact.

    My first message links to other forums and sites which gave me reason to think it will work.

    Robin

  5. #55
    Hi Robin,

    Thanks for the quick reply.

    I will give it a go and let you know how it goes...

    Cheers

    Andy

  6. #56
    Well I tried to give it a go, my shaky hands are not up to soldering a wire onto pin 15.

    Does anyone know when the "proper" debug functionality will be added to the Teensy so I don't need to hold pin 15 to ground or remove the chip?

    Cheers

    Andy

  7. #57
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,442
    Up to now, and for many, many years, most people, starting by Paul himself, were able to write their code in a smart enough way to not need that debug functionality, but they have been ingenious enough to do everything with the internal LED, Serial.print, an oscilloscope and a logic analyzer. Thus, I don't think that it's high on whomever's priority list...

  8. #58
    Thanks for the info.

    Unfortunately over the years I have learnt that I am not that smart and need debugger functionality. I understand the importance of a Logic Analyser/Oscilloscope for real time analysis of signals but a proper debugger is for everything else. I guess companies like Segger wouldn't be there otherwise.

    I think the Teensy 3.5 and 3.6 look like great boards, the library side of it is great, within an hour of plugging it in I had a midi and audio device running with rawhid, apart from the programming problem which you helped me overcome everything went swimmingly, very impressed.

    Debugger functionality though I think is very important, I got the 3.6 because it had the debug pins and not being that smart I didn't look into it enough, I just expected it to work.

    I am just wondering if Paul has a estimated date when this might by implemented, at a guess (unless there was a hardware design issue) this is just a simple firmware change to enable this unless I am missing something obvious?

  9. #59
    Hi Guys,

    I got the debugging going

    As I said before I couldn't solder a wire to the reset pin so after buying another teensy 3.6 to test on I just cut the PCB trace going to the pin 1 (power) of the KL02Z and added a pull-up resistor (4.7K) between reset and 3.3v, this is currently being done on the breadboard at the top of the image, I'm going to solder it under the header now I know it works.

    All working fine with Ozone for programming and debugging, next job is to get it all going in the Sloeber IDE.

    Well chuffed.

    Andy
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	TeensyDebug.jpg 
Views:	85 
Size:	211.8 KB 
ID:	13638  

  10. #60
    After some intermittent problems I also cut the traces to pins 4 and 13 on the MKL02Z, now it is reliable.

    I also have a template project for Teensy/Arduino builds in MCUXpresso which offers pretty good support for debugging, if anyone wants it send me a PM.

  11. #61
    Senior Member
    Join Date
    Feb 2015
    Posts
    160
    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.
    Hi Paul!

    I am curious if this ever got snuck in to the newer bootloader ICs? I designed a board way back when with this debug connector, and now im running into some problems that would be really nice to debug, and I have a sneaking suspicion that the firmware on my bootloader chip is not tri-stating the SWDIO and SWCLK pins when I bring the PTA3 pin on the MKL04 low. I have a 10k pullup on SWDIO as per the NXP JTAG connector spec, but the line still is driven low.

  12. #62
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,175
    Quote Originally Posted by tenkai View Post
    I am curious if this ever got snuck in to the newer bootloader ICs?
    Nope, it was never done.

  13. #63
    Junior Member
    Join Date
    Oct 2017
    Location
    UK
    Posts
    9
    Shame it was never updated...

    Simplest hack is to link pins 15 and 3 of the MKL02 on the Teensy 3.6 (linking the MKL02's RST to the 'DE' pin). Then, holding 'DE' low will freeze the Teensy loader chip, allowing full SWD access to the main CPU. :-)

    (See https://medium.com/@mattmatic/preparing-teensy-3-6-for-swd-b014b0ce2999 for some images )

    Matt

  14. #64
    Junior Member
    Join Date
    Mar 2019
    Location
    Germany
    Posts
    7
    PlatformIO has now opened their Plus Version for open source so you can use the PlatformIO Unified Debugger free of charge.

    https://community.platformio.org/t/p...medium=piohome

    But as far as I know, only JLink is possible for Teensy 3.6 and not even "out of the box".

    Is a better support planned for hardware debugging on Teensy 4.0?


    My old fashioned Arduino Due may be far inferior to my new bought Teensy 3.6 but at least it has got ICSP and JTAG debug connectors on board…

  15. #65
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,837
    I watched a video of that newly free PlatformIO debugging the ESP32 w/Arduino - demo looked like PC program debugging: conditional breakpoints, step into and out of, see var values, change var values all with full source.

    Paul noted 'there is a plan for T4 debugging' - but that was the only detail I saw.

Posting Permissions

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