芯片

芯片

关注
发信
关注(28)粉丝(399)

embedded - 如何使用OpenOCD ping芯片(检测是否连接了芯片)

1.问题解释

我正在尝试将OpenOCD用于不常见的事情。除了将连接到芯片外，我只想检测芯片上的。
我想到的过程将如下所示:



以下是有关该过程的更多注意事项:

注1:如果OpenOCD不能达到需要设置Telnet或GDB客户端与之交互的服务器状态，那就太好了。我很乐意以更方便的方式获得芯片检测报告，例如在stdout channel 上获取芯片信息。

注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传输协议(protocol)(而不是JTAG)，所以我对该示例进行了一些修改:

# openocd.cfg file
# -----------------
    source [find interface/stlink.cfg]
    transport select hla_swd
    reset_config srst_only
    adapter_khz 480

我将 NUCLEO_F303K8 板连接到PC进行此测试。然后，在控制台中发出以下命令:



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协议(protocol)进行自动探测吗？还是我只是在.cfg文件中犯了一个错误？

问题3:
我注意到第10.7节中的“自动探测”示例配置了OpenOCD的重置行为。从自动复位芯片的意义上来说，这是否意味着自动探测将始终是“侵入式”的？

问题4:
无论如何，第10.7节中的自动探测示例似乎使OpenOCD进入服务器状态。有可能避免这种情况吗？我想使这种“芯片检测”问题保持简单，而无需Telnet或GDB客户端。

编辑

谢谢@nattgris的出色回答。不过，我还有其他一些实际问题。

1.使用ST-Link

假设我们正在使用ST-Link，尽管它与OpenOCD的合作欠佳。你说:



我实际上如何说服ST-Link做到这一点？换句话说，我应该在openocd.cfg文件中添加什么来实现此目的？

2.使用SWD探针(但不使用ST-Link)

假设我们使用的是真正的SWD探针。你说:



据此，我得出以下结论:

第10.7节中所述的
  • 自动探测仅适用于JTAG，不适用于SWD。
  • 由于自动探测不适用于SWD，因此另一种方法是简单地连接到芯片，然后OpenOCD自动打印DPIDR寄存器。可以说，这个DPIDR寄存器与JTAG TAP IDCODE的SWD等效，并且可以在某种程度上识别芯片。
    但是，如果首先不知道将哪个芯片连接到PC，该如何简单地连接到芯片？如果我没记错的话，OpenOCD总是需要特定的配置文件(例如stm32f7x.cfg，stm32f4x.cfg，stm32l0.cfg，...)连接到芯片。
  • 显然，JTAG IDCODE和与SWD等效的DPIDR寄存器提供了芯片设计器，对于ARM-Cortex芯片而言，它始终是“ARM”。这还不足以进行完整的芯片识别。但是，您说的是ARM芯片具有单独的边界扫描TAP，它们提供了更多的IDCODE寄存器以进行更完整的标识。不幸的是，这些仅是JTAG。这意味着在芯片识别方面，SWD处于死胡同吗？
  • 使用JTAG自动探测(并因此读取IDCODE reg)可能是完全非侵入式的。因此，可能会使系统复位信号不可用:reset_config none您说通过SWD读取DPIDR(我认为这与JTAG自动探测的SWD等效)也是非侵入性的。我还可以通过使重置信号不可用来强制执行这种“非侵入性”吗？


    • 3.使用JTAG探针(但不使用ST-Link)

    JTAG协议(protocol)似乎为芯片识别(使用自动探测)提供了最佳支持。我的结论:
  • 第10.7节中描述的自动探测将从芯片上打印TAP IDCODE。对于仅打印“ARM”的ARM芯片，而不是实际制造商(例如“ST”)和芯片名称(例如“STM32F767ZI”)。
  • 我如何切实确保该程序还打印这些进一步的信息，尤其是实际的芯片名称？换句话说，我应该在openocd.cfg文件(可能还有openocd启动命令)中放置什么以实现此目的？

    • 非常感谢你 :-)

    最佳答案

    问题1:

    这是您所需要的吗？要看。如10.7节所述，自动探测仅与JTAG相关。因此，它本身无法满足您的需求。但是，仅通过SWD连接就可以打印相应的信息(DPIDR寄存器而不是TAP IDCODE)，因此无论哪种方式，您都可以通过两种协议(protocol)获得有关芯片的类似信息。

    但是，我不确定这是否足以满足您的需求。如果您只想检测一个芯片(任何芯片)有响应，这可能就足够了。如果您还需要详细标识芯片，则通常需要进一步检查，因为通过两种方法获得的ID码都可以标识芯片的设计者。因此，对于所有Cortex芯片，您基本上都会得到“ARM”，而不是芯片的实际制造商(例如“ST”)。虽然ST(可能还有其他制造商)芯片具有单独的边界扫描TAP(即仅JTAG)，但它提供了可用于芯片识别的实际ST IDCODE。

    但是，由于SWD仅与ARM Cortex类型(或ADI v5)目标相关，因此，如果可以使用SWD，则还可以读取调试组件的ROM表，其中除其他内容外，还提供了芯片制造商的信息:

    # 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

    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

    对于非Cortex芯片，仅通过自动探测就可以使用JTAG TAP IDCODE获得良好的标识，例如在此示例中使用旧的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)

    问题2:

    如上所述，“自动探测”仅与JTAG相关，但是您也可以通过SWD获得相同的功能(读取ID代码)。不幸的是，这对您没有帮助，因为您无权访问这两种协议(protocol)!

    问题是您使用的是ST-Link。尽管人们倾向于思考，但这并不是真正的JTAG/SWD适配器。是的，它同时具有JTAG和SWD的功能，但它完全将协议(protocol)隐藏在适配器固件中。它仅向主机(OpenOCD)提供高级命令集，其类型为“重置目标”，“步进目标”，“读取此存储器”等。因此，ST-Link的OpenOCD支持是一个丑陋的hack，它位于目标层而不是适配器层。因此，OpenOCD的大多数适配器，传输级别或DAP级别的功能根本不存在，并且从OpenOCD的意义上讲，自动探测与您的设置完全无关。

    为了进行简单的刷新和非常基本的GDB调试，可以使用ST-Link。但是，对于任何更底层的内容，请远离ST-Link。对于OpenOCD来说，这根本不是一个很好的选择。

    就是说，如果您只需要知道是否有芯片，则在某些配置中，可以说服ST-Link为您提供该信息，例如，使用以下配置文件:
    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

    你会得到
    Warn : UNEXPECTED idcode: 0x2ba01477

    或者
    Error: init mode failed (unable to connect to the target)

    其余问题与ST-Link无关，因此我假设您切换到了真正的JTAG/SWD适配器。

    问题3:

    JTAG自动探测以及通过SWD读取DPIDR完全是非侵入性的。通常，对于Cortex-M目标，大多数对目标的调试访问都是非侵入式的，因此您可以在目标几乎不运行的情况下读/写内存等，而不会影响目标。

    JTAG完全没有定义或要求系统复位信号可用。没有它，自动探测就可以正常工作，您应该可以使用
    reset_config none

    问题4:

    您是否要完全避免启动gdb服务器/telnet服务器？然后，您可以使用以下配置禁用它们:
    gdb_port disabled
telnet_port disabled
tcl_port disabled

    但是，如果您只是启动OpenOCD以检测芯片，然后将其关闭，则暂时启动这些服务可能不是问题。

    而且，至少GDB服务器仅在创建目标后才启动，这对于执行JTAG自动探测不是必需的。

    摘要

    是的，您应该能够做您想做的事，但也许不能使用ST-Link。使用真正的适配器，您可以执行JTAG自动探测，以在扫描链上打印检测到的TAP。对于SWD，OpenOCD始终打印检测到的DPIDR寄存器(如果找不到目标，则通常会中断；至少输出会有所不同)。

    如果目标本身支持连接/检测，那么它可以是完全非侵入性的，就像大多数Cortex-M一样。如果目标固件禁用了调试引脚或关闭了调试逻辑，则可能需要保持或脉冲复位，具体取决于目标。

    关于embedded - 如何使用OpenOCD ping芯片(检测是否连接了芯片)，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/56951820/

    10-10 19:48
    Powered by LMLPHP ©2025 芯片 0.033588