1.问题说明
我正在尝试将 OpenOCD 用于不常见的事情。我不想连接到芯片，而只想检测芯片。
我想到的程序如下所示：
stlink.cfg使用作为-f参数给出的探针配置文件（例如 ）启动 OpenOCD 。所以 OpenOCD 知道使用什么探针，但不知道它会找到什么芯片。OpenOCD 检测到芯片并以某种方式报告（例如，向标准输出写入内容）。如果可能，此操作不应侵入芯片（如重置它）。
OpenOCD 关闭。
以下是有关该过程的更多说明：
注意 1：如果 OpenOCD 没有达到我需要设置 Telnet 或 GDB 客户端与之交互的服务器状态，那就太好了。我很乐意以更方便的方式报告芯片检测，例如在标准输出通道上获取芯片信息。
注2：检测应不侵入芯片。但是，如果 OpenOCD 没有找到任何东西，我想要一种备份方法，让 OpenOCD 尝试更积极地找到芯片（比如按住nRST引脚）。如果需要，我可以自己调用其他方法（因此 OpenOCD 不需要自动执行此操作）。
注 3：首先，我将仅在带有 STLinkV2 或 STLinkV3 探针的 STM32 芯片上应用此“芯片检测”，稍后还将在其他探针和芯片上应用。
注 4：有些板只有一个 SWD 连接（没有 JTAG）。
注意 5：我正在使用 Windows 10 计算机，并获得了从https://www.playembedded.org/blog/download/下载的最新 OpenOCD 版本（版本0.10.0_dev00921，构建于2019 年 7 月 6 日）
2.到目前为止我尝试过的
Tommy Murphy 先生向我介绍了 OpenOCD 参考手册中的第 10.7 节（参见http://openocd.org/doc/pdf/openocd.pdf）。我已阅读该部分并观察了以下示例：
# openocd.cfg file
# -----------------
source [find interface/olimex-arm-usb-tiny-h.cfg]
reset_config trst_and_srst
jtag_rclk 8
因为我的芯片通过STLink 探针连接并使用SWD 传输协议（而不是 JTAG），所以我对示例进行了一些修改：
# openocd.cfg file
# -----------------
source [find interface/stlink.cfg]
transport select hla_swd
reset_config srst_only
adapter_khz 480
我将NUCLEO_F303K8板连接到我的 PC 以进行此测试。然后我在控制台中发出以下命令：
> openocd -s "C:\...\scripts" -f "C:\...\openocd.cfg"
OpenOCD 输出以下内容，然后终止：
Open On-Chip Debugger 0.10.0+dev-00921-gef8c69ff9 (2019-07-06-01:00)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 480 kHz
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 480 kHz
Error: BUG: current_target out of bounds
所以我最终提出了一些关于自动探测的问题。
3. 我的问题
问题 1：
“自动探测”（如第 10.7 节所述）真的是我需要的吗？如果答案是否定的，请忽略接下来的问题。
问题 2：
我尝试模仿第 10.7 节中给出的示例，稍作修改以使示例适合我的 Nucleo 板。不幸的是，自动探测失败。这是因为 OpenOCD 不支持使用 SWD 协议进行自动探测吗？或者我只是在我的.cfg文件中犯了一个错误？
问题 3：
我注意到第 10.7 节中的 Autoprobing 示例配置了 OpenOCD 的重置行为。这是否意味着自动探测在重置芯片的意义上总是“侵入性”的？
问题 4：
第 10.7 节中的 Autoprobing 示例似乎无论如何都将 OpenOCD 带入了服务器状态。有可能避免这种情况吗？我想让这个“芯片检测”保持简单，不需要 Telnet 或 GDB 客户端。
编辑
感谢@nattgris 的出色回答。不过，我还有一些更实际的问题。
1. 使用 ST-Link
假设我们使用的是 ST-Link，尽管它与 OpenOCD 的合作并不理想。你说：
.. 如果您只需要知道芯片是否存在，在某些配置中，ST-Link 可能会被说服为您提供该信息。
我实际上如何说服ST-Link 这样做？换句话说，我应该在我的openocd.cfg文件中放入什么来实现这一点？
2. 使用 SWD-probe（但不是 ST-Link）
假设我们使用的是真正的 SWD 探针。你说：
如第 10.7 节所述，自动探测仅与 JTAG [...] 相关。只需通过 SWD 连接即可打印相应的信息（
DPIDR寄存器而不是 TAPIDCODE）。因此，无论哪种方式，您都可以通过两种协议获得有关芯片的类似信息。[...]
对于所有 Cortex 芯片，您基本上会得到“ARM”而不是芯片的实际制造商（例如“ST”）。虽然 ST（可能还有其他制造商）芯片具有单独的边界扫描 TAP（即仅 JTAG），但它提供了IDCODE可用于芯片识别的实际 ST。
由此，我得出结论：
第 10.7 节中描述的自动探测仅适用于 JTAG，不适用于 SWD。
由于 SWD 无法使用 Autoprobing，因此另一种方法是简单地连接到芯片，然后 OpenOCD 会自动打印
DPIDR寄存器。该DPIDR寄存器相当于 JTAG TAP 的 SWDIDCODE，可以说是可以在一定程度上识别芯片。但是，如果一个人一开始不知道连接到 PC 的芯片是什么，那么
如何简单地连接到芯片上呢？如果我没记错的话，OpenOCD 总是需要特定的配置文件，比如stm32f7x.cfg,stm32f4x.cfg,stm32l0.cfg, ... 来连接到芯片。显然，JTAG
IDCODE和 SWD 等效DPIDR寄存器为芯片设计者提供，对于 ARM-Cortex 芯片来说，它始终是“ARM”。这对于完整的芯片识别是不够的。但是，您说 ARM 芯片具有单独的边界扫描 TAP，提供更多IDCODE寄存器以进行更完整的识别。不幸的是，这些只是 JTAG。这意味着SWD在芯片识别方面处于死胡同？使用 JTAG 进行自动探测（因此读取
IDCODEreg）可以是完全非侵入式的。因此，可以使系统复位信号不可用：reset_config none
您说读取DPIDR过度 SWD（我认为这是 JTAG 自动探测的 SWD 等效项）也是非侵入性的。我还可以通过使重置信号不可用来强制执行“非侵入性”吗？
3. 使用 JTAG-probe（但不是 ST-Link）
JTAG 协议似乎为芯片识别提供了最好的支持（使用 Autoprobing）。我的结论：
第 10.7 节中描述的自动探测
IDCODE将从芯片打印 TAP。对于只打印“ARM”的 ARM 芯片，而不是实际的制造商（如“ST”）和芯片名称（如“STM32F767ZI”）。我实际上如何确保该程序还打印这些进一步的信息，尤其是实际的芯片名称？换句话说，我应该在我的
openocd.cfg文件（可能还有 openocd 启动命令）中放入什么来实现这一点？
非常感谢 ：-）