Debugging strategies

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
 
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/5052...ion)-code-hangs-on-show()?p=172951#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);
};
 
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.

View 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
 
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
 
Hi Robin,

Thanks for the quick reply.

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

Cheers

Andy
 
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
 
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...
 
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?
 
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
 

Attachments

  • TeensyDebug.jpg
    TeensyDebug.jpg
    211.8 KB · Views: 574
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.
 
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.
 
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
 
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/platformio-plus-goes-open-source-improving-embedded-development-community-worldwide/8240?utm_source=platformio&utm_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…
 
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.
 
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.

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

Hello,

Great post. To confirm, for the Teensy 3.5, if a jumper wire is soldered to KL02Z pin 15 to ground, the Segger J-link (using an IDE that supports JTAG) can be used to debug the Teensy 3.5?

Thanks
 
I did not proceed any further testing this with a debug adaptor, due to other priorities. Now my interest is in connecting an SWD debugger to the Teensy 4.0:https://forum.pjrc.com/threads/57365-Teensy-4-0-how-to-connect-a-jtag-debugger?p=221753

This is trickier, since the 1062 MCU has a fuse blown which prevents it being used with an SWD debugger. I have had a fresh 1062 MCU reflowed on to my Teensy 4.0 but it may be a month or two before I try it out, in part because I am waiting for a MIMXRT1050-EVK to arrive so I can learn about SWD debugging with that, and MCUXpresso, before attempting the modifications required for the Teensy 4.0.
 
I did not proceed any further testing this with a debug adaptor, due to other priorities. Now my interest is in connecting an SWD debugger to the Teensy 4.0:https://forum.pjrc.com/threads/57365-Teensy-4-0-how-to-connect-a-jtag-debugger?p=221753

This is trickier, since the 1062 MCU has a fuse blown which prevents it being used with an SWD debugger. I have had a fresh 1062 MCU reflowed on to my Teensy 4.0 but it may be a month or two before I try it out, in part because I am waiting for a MIMXRT1050-EVK to arrive so I can learn about SWD debugging with that, and MCUXpresso, before attempting the modifications required for the Teensy 4.0.

I don't understand, why would PJRC continue to purposely make debugging teensy hard?
I've personally mostly switched to ESP32 because it has out of the box tracebacks and reliably serial output. I'm disappointed though as I was looking forward to teensy 4 to improve this :-/
 
I don't understand, why would PJRC continue to purposely make debugging teensy hard?
I've personally mostly switched to ESP32 because it has out of the box tracebacks and reliably serial output. I'm disappointed though as I was looking forward to teensy 4 to improve this :-/

It seems the Teensy modules were not designed to have debug support. This should explains the difficulty in connecting JTAG debuggers and the work done by Robbin Whittle.
 
Mmmh, but this thread is 2.5 years old, and Paul knows about it and replied here. It's disappointing that teensy 4 made no apparent changes to make this easily possible, and worse, seems to have a design that still makes it difficult ("1062 MCU has a fuse blown which prevents it being used with an SWD debugger", that's disheartening...).
 
The ARM Cortex-M7 debug features are exactly the same with JTAG as they are with SWD. Lack of support for SWD doesn't mean you can't connect a debugger. It merely means your debugger needs to speak JTAG protocol and connect with 4 or 5 signals instead of only 2 signals.

If you have a SWD-only debugger, you'll need to get one which uses JTAG protocol.

NXP designed the IMXRT chip to make JTAG and SWD mutually exclusive. Why they did it this way, I do not know. They could have made it switchable between these 2 on-the-fly, as they did with Kinetis. They could have put a JTAG-AP inside the chip on the DAP bus, to make the JTAG-only stuff accessible by SWD (and they could have put the very nice Kinetis MDM-AP into this chip, but sadly did not). They could have used a pin to somehow configure which protocol is used, similar to the boot config pins. But NXP did none of these things. For reasons I do not know, NXP made the chip so only 1 protocol is used, controlled by an OTP fuse bit.

Some important features are only available in JTAG mode, especially boundary scan. We use boundary scan for the 15 sec restore process. It's also used for testing the pins on a bed-of-nails test fixture. Since boundary scan is impossible to access when the chip is configured for SWD, we must configure Teensy 4.0 for JTAG.

The absence of SWD doesn't mean you can't connect a debugger. It only means you need to use a debugger which speaks JTAG protocol rather than SWD protocol. If you remove the MKL02 chip or otherwise modify the hardware to access the signals, you simply need to connect to 5 signals (TMS, TCK, TDI, TDO, MOD) instead of 2 (SWDIO, SWCLK). The JTAG MOD pin can be tied to GND if you wish to only access ARM debug, so you only need 4 signals.

If your ARM debugger is SWD only, this is the time to stop complaining and start shopping for one which speaks JTAG protocol.
 
Thanks Paul for this information. As it is pertinent to the Teensy 4.0 discussion I quoted what you wrote there: https://forum.pjrc.com/threads/57365-Teensy-4-0-how-to-connect-a-jtag-debugger?p=221753 msg 21.

As I wrote there I have no experience with any of this stuff. I thought that SWD was the only way of connecting a debug probe. I am reading what initially resembles alphabet soup in an effort to derive actual knowledge. This will be easier when I have the MIMXRT1060-EVK and get it working with the LPC-Link2, by SWD and/or JTAG protocols.
 
The ARM Cortex-M7 debug features are exactly the same with JTAG as they are with SWD. Lack of support for SWD doesn't mean you can't connect a debugger. It merely means your debugger needs to speak JTAG protocol and connect with 4 or 5 signals instead of only 2 signals.

If you have a SWD-only debugger, you'll need to get one which uses JTAG protocol.

Totes fine with using a Segger J-link. I am currently debugging my teensies 3.2-3.6 with them, but you also mentioned power supply sequencing issues that might arise when removing the MKL02 here:

https://forum.pjrc.com/newreply.php?do=newreply&p=214478

This would lead me to believe that simply removing the MKL02 may result in inconsistent or even unreliable DCDC controller operation. Would the "Debug Enable" feature for the MLK02 be something that could really help here? I am considering getting my own MKL02 and writing a custom firmware to tri state all pins, and also do the power supply sequencing.

I haven't actually tried removing the MKL02 and connecting a JTAG connector yet. Something I plan to work on soon, as I am starting a new project and need to figure out how to debug properly on the Teensy 4
 
Since I am in desperate need of SWD debugging on Teensy 3.6 but dont feel up to the task of soldering to the bootloader chip: Isn't there any way to simply crash or stall the bootloader chip after upload, so it doesn't interfere with the signals any more? I think at this point, with people desoldering chips, any unsupported, hacky solution would be totally fine with the people who actually require a debugger and then Paul could probably put this topic to rest.
 
Back
Top