USB Debug, JLink, KitProg3

tldr; Use KitProg3 with PSOC Creator from Windows to connect. Starts ARM Debug On USB pins, regardless of current USB port usage.

USB Debug Fail — OPENOCD, JLINK

If the USB port is used, or those pins are used for other purposes, then neither OPEN OCD nor JLINK can connect to the PSOC 5 using those pins as of July, 2024. This may be resolved in the future (but don’t hold your breath). This is a pain if you are using Mac or Linux to do your debug using VsCode with Cortex-Debug, and your device uses the USB port, for example.

You can use PSOC Creator to do your debug, and that gives you a sneaky way into the PSOC along with possibly using JLINK. But it is annoying because you have to plug/unplug devices. However, the JLINK is a much faster debugger package than the KitProg, so you might want to do that.

You Can Always Use P1.0 (SWDIO), P1.1 (SWCLK) Pins on PSOC 5 To Debug

If you *do not* use P1.0 and P1.1, then you can Attach Using OPEN OCD, JLINK, or KitProg3 and debug your PSOC5, regardless of the status of the USB. The Arm Internal Debugger Hardware handles this for you. It automatically recognizes the handshake pattern and can interrupt a running processor without resetting it.

If You use PC’s Menu “Select Debug Target” You Can Attach Over the USB Pins

BUT…..You must Use KitProg3 to do this “connect” with, from the Windows Environment, Using PSOC Creator. (You can use KitProg 1 in “Kitprog” mode to get the device’s attention.) NOTE: I use the “reset” line wired through the spare pin (5 pins on Mini USB instead of 4) on a Mini USB connector to be able to hardware force a PSOC reset when connecting. This pin is not wired through in all Mini USB cables I have seen.

Once You have “Connected” using PSOC Creator Under Virtual Box/VMware, Then..

…Disconnect the USB device from your Virtual Machine, and software connect with VsCode Cortex-Debug (From Marus) on the Macintosh. From that point on, things flow normally, using VsCode to debug with. This is a song and dance, but not a huge problem in my setup. (See previous posts.)

If you use JLINK, you would then need to physically disconnect the cable from the KitProg3 and physically connect the cable to the JLINK. For the JLINK, I use a $5 adapter board with short jumper cables soldered on the board, going to the USB cable in the “right” order. See previous posts for programming the Kitprog.

Check To See If Debugger Attached

I use the following code to see if debugger is attached, and set a global variable so my other code can key off being debugged. You could possibly put the code in an infinite loop near the end of the programmed flash to make it harder for people trying to see what you are doing, assuming they connect a debugger.

I use it to prevent enabling the USB and re-routing debug i/o data to a UART. Each board build has a complex set of tools built in to enable production to customize the part (low volume):

    // if the debugger is connected, set the global debug flag
    if (CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk){
            // Debugger is connected.  This will trigger
            // changes for the TerminalDebug program
            // For this version of code, we cannot use USB for debug
            // terminal if the debugger is connected.  We must use
            // the serial port.
            gDebuggerIsConnected=1;           
    }

Generically: Why Use VsCode? Why Use JLINK?

Simple Answer 1: Speed of compile and Debug. VsCode native on Mac is 5 to 100 times faster than using PSOC Creator when doing Compile/Debug/Code Change/Compile/Debug….especially if you have a Mac Fusion drive, or an M2 flash drive. JLINK is noticeably faster than KitProg 3, but it is a small enough margin to not appreciably slow down your debugging, in my experience.

Simple Answer 2: Ground Loops. For that, use an Isolated JLINK debugger.

Longer answer, I had a third party switching power supply hooked up to another 3rd party switching power supply that was powering the first switcher. The second switcher also powered my switching power supply which runs a PSOC5, and that PSOC5 is connected to a computer powered by the first switcher. The grounds are noisy, and current circulation loops are inevitable when attaching my computer, which has another switcher and some USB protection grounds. It failed when I tried to connect to my PSOC5 mcu board.

For this situation, there was no way to debug the PSOC5 using any Kitprog device. (I tried.) I eventually had to use an Infineon XMC ™ Link Isolated debugger. (Was $90 last year.) That works for PSOC5 using the JLINK setup from Cortex-Debug on VSCode. Fortunately I was using the SWDIO/SWCLK lines, so no problems acquiring the processor. JLINK was able to connect to the Arm Debugger Hardware without issue, program the PSOC, and do debugging.

Fini

Rapid Application Development (RAD) is still in play under different names. Debugging your code faster and faster is the current key to getting product to market in time.

Enjoy!

Add a Comment

Your email address will not be published. Required fields are marked *