PSOC5 JLINK & KitProg Debugging

Posted On August 28, 2024

After experimenting with the USB port and debugging, I have uncovered some details not in the literature.

JLINK Without Reset Line

You can get the attention of an ARM processor’s Debug hardware using SCLK and SDIO without resetting the processor. That lets you “attach” to the processor and see where it is currently executing. I have used this to uncover stupid programmer tricks ™ and other issues where there are race conditions.

(Extra Info: A “race” condition happens when two or more signals depend upon a certain sequence for the hardware (or firmware) to operate as intended. In certain situations, an unexpected signal or signal sequence can cause a signal to be misread or transition (or “glitch”) when it was not expected. That can be bad. Or it can be a non-event.)

If the firmware or hardware gets into a race condition that prevents further operation, the processor can be said to be “locked up,” or the hardware can be said to be “frozen.” Or Vice-Versa.

When using VSCode with Cortex-M, and a JLINK, you can attach to the running processor. Or you can get its attention and halt the processor, reprogram the flash, then start debugging. Most of the time.

Debug Gotcha Synopsis

I designed a board for testing (and eventual production) purposes using the PSOC5 USB debug platform. Here is what I have learned when using VSCode and Cortex-M:

• You can use J-Link to get a PSOC5 attention on the SWDIO and SWCLK Lines without a Reset Line wired
• You cannot use J-Link to get a PSOC5 attention on the USB Port even with a Reset Line wired
• You can use a KitProg3 to get a PSOC5 attention on the USB Port with a Reset line wired
• I have not been able to use a KitProg3 to get a PSOC5 attention on the SWDIO and SWCLK lines without a Reset Line wired. This may be a configuration issue with the current OpenOCD.

JLINK Debugging Gotchas without Reset Line on VSCode

Even with the JLINK, I ran into some issues:

• The JLINK will often not be able to get the PSOC5 attention the first time.*
• The JLINK Firmware will *sometimes* appear to be very weird after many attempts at getting the processor attention without a reset line. Power cycling the probe fixes this problem. I believe this is a stack overflow problem.

*If you do not get the processor’s attention the first time, simply click on the disconnect icon and start the VSCode debug process from the beginning. It will connect 90% (or more) of the time on the second try. If it does not, power cycle the target. If that does not work, also power cycle the debug probe.

Debug Gotchas with PSOC5 USB Port

If you use a USB Port in your schematic design, you may have trouble debugging on the USB pins. You can program the PSOC5 over the USB (using the KitProg3), but debugging may not be available, even if you recognize the debugger is attached and do not initialize the USB Port. (See my previous posts about using the USB Port and debugging.)

My guess is the presence of the USB in the project causes the I/O lines to be pre-emptively configured so the ARM debugging facilities on those pins become non-functional. You can still get the processor’s attention on the P1 port and use that port to debug with.

This is disappointing, but crying over spilled milk does not help. Always provide yourself with a way out, which I did by providing access to the swdio and swclk P1 pins, “just in case.” Was a good move on my part.

Fini

It is disappointing that using the USB port pins for debugging has such limitations. Still, using the USB allowed us to streamline our low volume production and move away from the MiniProg with its connectors that wear out *much* faster than the USB connectors.

Enjoy!