Debugging strategies

[eecode00]

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.

I know this is an old thread.
Will cutting the RESET trace to the MKL02 work in getting SWD debugging working? This assumes soldering headers to the Teensy 3.5 to connect a SWD debugger like Segger J-link. It was mentioned earlier to cut this trace instead of soldering a jumper or removing the MKL02.

Although it's been described in another post, I setup the Eclipse C\C++ IDE using Arduinio\Teensy libraries and the Teensyduino loader program.
I can compile and download code to the Teensy 3.5, but debugging will be great (e.g., single stepping, looking at registers, breakpoints, etc.).

 

[HI_Paul]

I know this is an old thread.
Will cutting the RESET trace to the MKL02 work in getting SWD debugging working? This assumes soldering headers to the Teensy 3.5 to connect a SWD debugger like Segger J-link. It was mentioned earlier to cut this trace instead of soldering a jumper or removing the MKL02.

Although it's been described in another post, I setup the Eclipse C\C++ IDE using Arduinio\Teensy libraries and the Teensyduino loader program.
I can compile and download code to the Teensy 3.5, but debugging will be great (e.g., single stepping, looking at registers, breakpoints, etc.).

The issue seems to be, that the KL02Z is still communicating with the main chip during runtime for unknown reasons, which is messing up external debugging sessions. Best guess, the KL02Z keeps a debugging session alive to reliably detect USB progamming and reboot requests, without depending on the main chip actually still running properly. I think the DE pin was intended to disable this behaviour, but the bootloader firmware seems to not have been finished before shipping and bootloader firmware updates are probably very tricky from a technical and business-risk perspective.

This is why I'm looking for ways to crash/block/silence/suspend the KL02Z somehow, either via USB or via startup-code on the Teensy, to put it into a state where its own reset has to be triggered for it to start up again instead of removing it or cutting traces (which incidentally I am not capable of because of very poor eyesight). I read somewhere, that the KL02Z can be disabled by putting the K66 into deep sleep, but I don't yet know whether this is permanent until reset or can be made to stick long enough for some useful debugging. The KL02Z also has its SWD interface broken out to two test points on the back, so maybe it can be halted via a second SWD session. I distinctly remember Paul warning to not mess with it, or to risk a bricked Teensy, which, come to think of it, may actually be what I am looking for.

 

[eecode00]

The issue seems to be, that the KL02Z is still communicating with the main chip during runtime for unknown reasons, which is messing up external debugging sessions. Best guess, the KL02Z keeps a debugging session alive to reliably detect USB progamming and reboot requests, without depending on the main chip actually still running properly. I think the DE pin was intended to disable this behaviour, but the bootloader firmware seems to not have been finished before shipping and bootloader firmware updates are probably very tricky from a technical and business-risk perspective.

This is why I'm looking for ways to crash/block/silence/suspend the KL02Z somehow, either via USB or via startup-code on the Teensy, to put it into a state where its own reset has to be triggered for it to start up again instead of removing it or cutting traces (which incidentally I am not capable of because of very poor eyesight). I read somewhere, that the KL02Z can be disabled by putting the K66 into deep sleep, but I don't yet know whether this is permanent until reset or can be made to stick long enough for some useful debugging. The KL02Z also has its SWD interface broken out to two test points on the back, so maybe it can be halted via a second SWD session. I distinctly remember Paul warning to not mess with it, or to risk a bricked Teensy, which, come to think of it, may actually be what I am looking for.

By removing the KL02Z and connecting a SWD debugger will work as it's been described in another post. The question is if cutting the trace that supplies VDD to the KL02Z and the trace that connects to RESET of the MK64 will allow a SWD debugger to work. You mentioned to brick the Teensy 3.5 which is essentially the removing the bootloader operation and using a debugger to program the flash.

Your idea is great to find a solution without board modification, but perhaps the KL02Z firmware will be updated to allow debugging.