Debug with STLink, have two connected, how do you tell debugger which one to use?

[tgioiosa]

This is probably a simple question, but I’m stuck. I have two targets I want to debug (with two instances of Platformio running. I also have two STLink’s, one for each target. How do I inform Platformio which STLink to use with each target?

[manuelbl]

It’s not straightforward but can be done. See these posts:

Choosing STLink V2 programmer

Not possible out of the box. You’ll have to modify the OpenOCD script to e.g. check for the existence of an environment variable like “SERIAL”, and then the script can use that serial to identify the correct STLinkv2. That’s how I’ve implemented a “flash firmware to a specific STLink” some time ago. The code for the modified stlink.cfg can be found at Programming with multiple ST-Link programmers (the new scripts all redirect to stlink.cfg). # # STMicroelectronics ST-LINK/V2-1 in-circuit debu…

More than one ST-Link for upload (several devices are connected to PC_

openocd is inherently unable to distinguish STLinks by default, but a modification can be done to check the serial. See Programming with multiple ST-Link programmers. This is different for every single upload tool, some might not even support it.

[tgioiosa]

Manuel, thank you. This is exactly what I need to do.

[zpm1066]

Interestingly, often I have multiple J-link, ST-link and CMSIS-DAP plugged into a USB hub for debugging, sometimes building from the terminal session for currently PIO unsupported boards (like BBC Microbit v2 under Zephyr) using “west flash” but mostly doing development under PlatformIO. I noticed that west will popup with a selection for the probe selection, for example.

It would be nice to have something like this for PlatformIO.

[tgioiosa]

Yes it would make things easier!

[maxgerhardt]

@zpm1066

This is from PyOCD.

PyOCD is integrated in PlatformIO for some platforms. It’s e.g. the standard for debugging and uploading to NXP LPC chips when using the upload_protocol = cmsis-dap (or debug_tool).

See e.g.

platformio/platform-nxplpc/blob/c033fccf9030263cc860904f47ca179578480e40/platform.json#L158-L163

platformio/platform-nxplpc/blob/241dc20e430fdc729f11eaaad9398949114ec5c4/platform.py#L101-L117

platformio/platform-nxplpc/blob/cad6d375656af8224cc80803a20a3827fc05e506/boards/lpc1768.json#L11-L15

Since you can arbitrarily change the debug_server you can point it to pyocd and in the commandlist you can give it a

  -u UNIQUE_ID, --uid UNIQUE_ID, --probe UNIQUE_ID
                        Choose a probe by its unique ID or a substring thereof. Optionally
                        prefixed with '<probe-type>:' where <probe-type> is the name of a probe
                        plugin

to get a pyocd gdb -u <unique ID of debugger> -t cortex_m invocation to start the GDB server. Works nicely.

C:\Users\Max\pyAVRdbg>pyocd gdb -u 066EFF575251717867125648 -t cortex_m
0001092:INFO:board:Target type is cortex_m
0001097:INFO:dap:DP IDR = 0x1ba01477 (v1 rev1)
0001100:INFO:ap:AHB-AP#0 IDR = 0x14770011 (AHB-AP var1 rev1)
0001105:INFO:rom_table:AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00ff000 (designer=020 part=410)
0001108:INFO:rom_table:[0]<e000e000:SCS-M3 class=14 designer=43b part=000>
0001110:INFO:rom_table:[1]<e0001000:DWT class=14 designer=43b part=002>
0001111:INFO:rom_table:[2]<e0002000:FPB class=14 designer=43b part=003>
0001113:INFO:rom_table:[3]<e0000000:ITM class=14 designer=43b part=001>
0001115:INFO:rom_table:[4]<e0040000:TPIU-M3 class=9 designer=43b part=923 devtype=11 archid=0000 devid=ca0:0:0>
0001116:INFO:cortex_m:CPU core #0 is Cortex-M3 r1p1
0001121:INFO:dwt:4 hardware watchpoints
0001124:INFO:fpb:6 hardware breakpoints, 4 literal comparators
0001141:INFO:server:Semihost server started on port 4444 (core 0)
0001149:INFO:gdbserver:GDB server started on port 3333 (core 0)

Might be easier than teaching OpenOCD tricks with respecting the serial number. Haven’t tried it yet in combination with PlatformIO though.