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.