How to ping a chip (detect if a chip is connected) with OpenOCD
Question 1:
Is this what you need? Depends. Autoprobing, as described in section 10.7, is only relevant for JTAG. So by itself, it won't cover your needs. But simply connecting via SWD prints the corresponding information (the DPIDR register instead of the TAP IDCODE) so either way, you can get similar info about the chip over both protocols.
However, I'm not sure if that's enough for you. If you only want to detect that a chip (any chip) responds, this is probably enough. If you also need to identify the chip in detail, further examination will in general be necessary, since the ID codes you get through both methods identifies the designer of the chip. So for all Cortex-chips, you will basically get "ARM" instead of the actual manufacturer of the chip (e.g. "ST"). Though ST (and perhaps other manufacturers) chips have a separate boundary scan TAP (i.e. JTAG only) that provides an actual ST IDCODE that can be used for chip identification.
However, since SWD is relevant only for ARM Cortex-type (or rather ADI v5) targets, if you can use SWD you can also read the ROM Table of the debug components, which provide among other things the manufacturer of the chip:
# Your JTAG adapter config
script interface.cfg
transport select swd
adapter_khz 100
swd newdap chip cpu -enable
dap create chip.dap -chain-position chip.cpu
target create chip.cpu cortex_m -dap chip.dap
init
dap info
shutdown
Output for an STM32F103:
Info : SWD DPIDR 0x1ba01477
Info : chip.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : gdb port disabled
AP ID register 0x14770011
Type is MEM-AP AHB
MEM-AP BASE 0xe00ff003
Valid ROM table present
Component base address 0xe00ff000
Peripheral ID 0x00000a0410
Designer is 0x0a0, STMicroelectronics
Part is 0x410, Unrecognized
Component class is 0x1, ROM table
MEMTYPE system memory present on bus
ROMTABLE[0x0] = 0xfff0f003
Component base address 0xe000e000
Peripheral ID 0x04001bb000
Designer is 0x4bb, ARM Ltd.
Part is 0x0, Cortex-M3 SCS (System Control Space)
Component class is 0xe, Generic IP component
ROMTABLE[0x4] = 0xfff02003
Component base address 0xe0001000
Peripheral ID 0x04001bb002
Designer is 0x4bb, ARM Ltd.
Part is 0x2, Cortex-M3 DWT (Data Watchpoint and Trace)
Component class is 0xe, Generic IP component
ROMTABLE[0x8] = 0xfff03003
Component base address 0xe0002000
Peripheral ID 0x04000bb003
Designer is 0x4bb, ARM Ltd.
Part is 0x3, Cortex-M3 FPB (Flash Patch and Breakpoint)
Component class is 0xe, Generic IP component
ROMTABLE[0xc] = 0xfff01003
Component base address 0xe0000000
Peripheral ID 0x04001bb001
Designer is 0x4bb, ARM Ltd.
Part is 0x1, Cortex-M3 ITM (Instrumentation Trace Module)
Component class is 0xe, Generic IP component
ROMTABLE[0x10] = 0xfff41003
Component base address 0xe0040000
Peripheral ID 0x04001bb923
Designer is 0x4bb, ARM Ltd.
Part is 0x923, Cortex-M3 TPIU (Trace Port Interface Unit)
Component class is 0x9, CoreSight component
Type is 0x11, Trace Sink, Port
ROMTABLE[0x14] = 0xfff42002
Component not present
ROMTABLE[0x18] = 0x0
End of ROM table
For non-Cortex chips, you will get good identification using the JTAG TAP IDCODE from autoprobing alone, like in this example with an old STR750:
# Your JTAG adapter config
script interface.cfg
transport select jtag
adapter_khz 100
init
shutdown
Info : JTAG tap: auto0.tap tap/device found: 0x4f1f0041 (mfg: 0x020 (STMicroelectronics), part: 0xf1f0, ver: 0x4)
Question 2:
As described above, "autoprobing" is only relevant for JTAG, but you get the same functionality (reading an ID code) over SWD as well. Unfortunately, that doesn't help you because you don't have access to either protocol!
The problem is that you use the ST-Link. Despite what people tend to think, this is NOT a true JTAG/SWD adapter. Yes, it speaks both JTAG and SWD, but it completely hides the protocol inside the adapter firmware. It only provides a high-level command set to the host (OpenOCD), of the type "Reset the target", "Step the target", "Read this memory" etc. As a consequence, the OpenOCD support of the ST-Link is an ugly hack, where it sits at the target layer instead of the adapter layer. So most adapter-, transport- or DAP-level features of OpenOCD simply does not exist and autoprobing in the OpenOCD sense is completely irrelevant for your setup.
For simple flashing and very basic GDB debugging, the ST-Link works. But for anything more low-level, just stay away from the ST-Link. It's not a good match at all for OpenOCD.
That said, if all you need is to know is whether a chip is there at all, in some configurations the ST-Link can probably be persuaded to give you that info, for example with the following configuration file:
script interface/stlink.cfg
transport select hla_swd
adapter_khz 100
hla newtap chip cpu -enable
dap create chip.dap -chain-position chip.cpu
target create chip.cpu cortex_m -dap chip.dap
You will get either
Warn : UNEXPECTED idcode: 0x2ba01477
or
Error: init mode failed (unable to connect to the target)
The rest of the questions are irrelevant together with an ST-Link, so I will assume that you switch to a real JTAG/SWD adapter.
Question 3:
JTAG autoprobing, as well as reading the DPIDR over SWD, is completely non-intrusive. For Cortex-M targets in general, most debug accesses to the target are non-intrusive so you can read/write memory etc. while the target is running hardly without affecting it.
JTAG does not define or require a system reset signal to be available at all. Autoprobing works fine without it, you should be able to use
reset_config none
Question 4:
Do you want to avoid starting a gdb server/telnet server at all? Then you can disable them with the following configuration:
gdb_port disabled
telnet_port disabled
tcl_port disabled
However if you just start OpenOCD to detect a chip and then shut it down, temporarily starting these services may not be a problem anyway.
Moreover, at least the GDB server is started only after creating a target, which isn't necessary to perform a JTAG autoprobe.
Summary
Yes you should be able to do what you want, but perhaps not with the ST-Link. With a real adapter you can do JTAG autoprobing to print detected TAPs on the scan chain. For SWD, OpenOCD always prints the detected DPIDR register (and generally breaks if no target is found; output will be different at least).
Connection/detection can be completely non-intrusive, if the target itself supports it, as most Cortex-M ones do. If target firmware have disabled debug pins, or powered down debug logic, you may need to hold or pulse reset, depending on the target.