本文介绍了如何使用OpenOCD ping芯片(检测是否连接了芯片)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

1.问题已解释

我正在尝试使用OpenOCD进行一些罕见的操作.我只想检测而不是连接到芯片.
我想到的过程将如下所示:

以下是有关该过程的更多说明:

注意1:如果OpenOCD没有达到需要设置Telnet或GDB客户端与之交互的服务器状态,那将是很好的选择.我很乐意以更方便的方式获得芯片检测报告,例如在stdout通道上获取芯片信息.

注2::该检测应该对芯片无干扰.但是,如果OpenOCD找不到任何东西,我希望有一种备份方法,其中OpenOCD尝试更积极地查找芯片(例如按住 nRST 引脚).如果需要,我可以自己调用其他方法(因此,OpenOCD不需要自动执行此操作).

注释3:首先,我将仅在带有STLinkV2或STLinkV3探针的STM32芯片上应用此芯片检测",然后在其他探针和芯片上也应用

.

注4::某些板仅具有SWD连接(无JTAG).

注释5:我正在Windows 10计算机上工作,并获得了最新的OpenOCD构建(版本 0.10.0_dev00921 ,该版本建于7月6日2019 )从 https://www.playembedded.org/blog/download/

 

2.到目前为止我尝试过的

先生.Tommy Murphy引用了OpenOCD参考手册中的10.7节(请参见 http://openocd.org/doc/pdf/openocd.pdf ).我已经阅读了本节,并观察了以下示例:

 #openocd.cfg文件#-----------------来源[查找接口/olimex-arm-usb-tiny-h.cfg]reset_config trst_and_srstjtag_rclk 8 

因为我的芯片通过 STLink探针连接并且使用 SWD传输协议(而不是JTAG),所以我对该示例进行了一些修改:

 #openocd.cfg文件#-----------------源[查找接口/stlink.cfg]传输选择hla_swdreset_config srst_onlyadapter_khz 480 

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

OpenOCD输出以下内容,然后终止:

  Open On-Chip Debugger 0.10.0 + dev-00921-gef8c69ff9(2019-07-06-01:00)根据GNU GPL v2许可有关错误报告,请阅读http://openocd.org/doc/doxygen/bugs.html适配器速度:480 kHz信息:在端口6666上监听tcl连接信息:在端口4444上侦听telnet连接信息:时钟速度480 kHz错误:BUG:current_target超出范围 

所以我最后遇到了一些有关自动探测的问题.

 

3.我的问题

问题1:
这里真的需要自动探测"(如第10.7节中所述)吗?如果答案为,请忽略下一个问题.

问题2:
我试图模仿第10.7节中给出的示例,并做了一些小的修改以使该示例适用于我的Nucleo开发板.不幸的是,自动探测失败.这是因为OpenOCD不支持使用SWD协议进行自动探测吗?还是我只是在我的 .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探针.你说:

据此我得出以下结论:

  1. 第10.7节中所述的自动探测仅适用于JTAG,不适用于SWD.

  2. 由于自动探测不适用于SWD,因此另一种方法是简单连接到芯片,然后OpenOCD自动打印 DPIDR 寄存器.可以说,这个 DPIDR 寄存器与JTAG TAP IDCODE 的SWD等效,并且可以在某种程度上识别芯片.
    但是,如果一个人一开始不知道将哪个芯片连接到PC,该如何简单地将连接到该芯片?如果我没记错的话,OpenOCD总是需要特定的配置文件,例如 stm32f7x.cfg stm32f4x.cfg stm32l0.cfg ,...连接到芯片.

  3. 显然,JTAG IDCODE 和与SWD等效的 DPIDR 寄存器提供了芯片设计器,对于ARM-Cortex芯片,该设计器始终为"ARM".这还不足以进行完整的芯片识别.但是,您说ARM芯片具有单独的边界扫描TAP,这些TAP提供了更多的 IDCODE 寄存器以进行更完整的标识.不幸的是,这些仅是JTAG.这意味着SWD在芯片识别方面处于死胡同?

  4. 使用JTAG自动探测(因此读取 IDCODE reg)可能是完全非侵入式的.因此,可能会导致系统重置信号不可用:
    reset_config none
    您说的是通过SWD读取 DPIDR (我认为这是SWD-等效于JTAG自动探测)也是非侵入性的.我还可以通过使重置信号不可用来强制执行这种非侵入性"吗?

 

3.使用JTAG-probe(但不使用ST-Link)

JTAG协议似乎为芯片识别(使用自动探测)提供了最佳支持.我的结论:

  1. 第10.7节中描述的自动探测将从芯片上打印TAP IDCODE .对于仅打印"ARM"的ARM芯片,而不是实际制造商(例如"ST")和芯片名称(例如"STM32F767ZI").

  2. 我实际上如何确保该程序还打印这些进一步的信息,尤其是实际的芯片名称?换句话说,我应该在我的 openocd.cfg 文件(可能还有openocd启动命令)中添加什么来实现这一目标?

 
非常感谢您:-)

解决方案

问题1:

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

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

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

 #您的JTAG适配器配置脚本interface.cfg运输选择SWDadapter_khz 100swd newdap芯片cpu-启用dap创建chip.dap-链式位置chip.cpu目标创建chip.cpu cortex_m -dap chip.dap在里面dap信息关掉 

STM32F103的输出:

 信息:SWD DPIDR 0x1ba01477信息:chip.cpu:硬件具有6个断点,4个观察点信息:gdb端口已禁用AP ID寄存器0x14770011类型是MEM-AP AHBMEM-AP基础0xe00ff003有效的ROM表存在组件基址0xe00ff000外围设备ID 0x00000a0410设计师是0x0a0,意法半导体部分为0x410,无法识别组件类为0x1,ROM表总线上存在MEMTYPE系统内存ROMTABLE [0x0] = 0xfff0f003组件基址0xe000e000外围设备ID 0x04001bb000设计师是ARM Ltd.的0x4bb部件是0x0,Cortex-M3 SCS(系统控制空间)组件类为0xe,通用IP组件ROMTABLE [0x4] = 0xfff02003组件基址0xe0001000外围设备ID 0x04001bb002设计师是ARM Ltd.的0x4bb零件是0x2,Cortex-M3 DWT(数据观察点和跟踪)组件类为0xe,通用IP组件ROMTABLE [0x8] = 0xfff03003组件基址0xe0002000外围设备ID 0x04000bb003设计师是ARM Ltd.的0x4bb零件是0x3,Cortex-M3 FPB(闪存补丁和断点)组件类为0xe,通用IP组件ROMTABLE [0xc] = 0xfff01003组件基址0xe0000000外围设备ID 0x04001bb001设计师是ARM Ltd.的0x4bb.零件是0x1,Cortex-M3 ITM(仪器跟踪模块)组件类为0xe,通用IP组件ROMTABLE [0x10] = 0xfff41003组件基址0xe0040000外围设备ID 0x04001bb923设计师是ARM Ltd.的0x4bb部件是0x923,Cortex-M3 TPIU(跟踪端口接口单元)组件类为0x9,CoreSight组件类型为0x11,跟踪接收器,端口ROMTABLE [0x14] = 0xfff42002组件不存在ROMTABLE [0x18] = 0x0ROM表尾 

对于非Cortex芯片,仅通过自动探测就可以使用JTAG TAP IDCODE获得良好的识别,例如在此示例中使用旧的STR750:

 #您的JTAG适配器配置脚本interface.cfg运输选择jtagadapter_khz 100在里面关掉 
 信息:JTAG抽头:auto0.tap抽头/找到的设备:0x4f1f0041(mfg:0x020(STMicroelectronics),零件:0xf1f0,ver:0x4) 

问题2:

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

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

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

也就是说,如果您只需要知道是否有芯片,在某些配置中,可以说服ST-Link为您提供该信息,例如,使用以下配置文件:

 脚本接口/stlink.cfg传输选择hla_swdadapter_khz 100hla newtap芯片cpu-启用dap创建chip.dap-链式位置chip.cpu目标创建chip.cpu cortex_m -dap chip.dap 

您将得到其中一个

 警告:UNEXPECTED idcode:0x2ba01477 

 错误:初始化模式失败(无法连接到目标) 

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

问题3:

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

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

  reset_config无 

问题4:

您是否要完全避免启动gdb服务器/telnet服务器?然后,您可以使用以下配置禁用它们:

  gdb_port已禁用telnet_port已禁用tcl_port已禁用 

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

此外,至少只有在创建 target 之后才启动GDB服务器,这对于执行JTAG自动探针不是必需的.

摘要

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

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

1. The problem explained

I'm trying to use OpenOCD for something uncommon. Instead of connecting to the chip, I'd like to merely detect the chip.
The procedure I have in mind would look like this:

Here are some more notes about the procedure:

Note 1: It would be nice if OpenOCD doesn't reach the server state where I need to setup a Telnet or GDB client to interact with it. I'd be happy to get the chip detection reported in a more convenient way, like getting the chip info on the stdout channel.

Note 2: The detection should be non-intrusive to the chip. However, if OpenOCD doesn't find anything, I'd like to have a backup method where OpenOCD tries to find a chip more aggressively (like holding down the nRST pin). I can invoke this other approach myself if needed (so there's no need for OpenOCD to do that automatically).

Note 3: At first, I'll just apply this "chip detection" only on STM32 chips with an STLinkV2 or STLinkV3 probe, later on other probes and chips as well.

Note 4: Some boards only have an SWD connection (no JTAG).

Note 5: I'm working on a Windows 10 computer, and got a very recent OpenOCD build (version 0.10.0_dev00921, built on 06 July 2019) downloaded from https://www.playembedded.org/blog/download/

 

2. What I've tried so far

Mr. Tommy Murphy referred me to Section 10.7 in the OpenOCD reference manual (see http://openocd.org/doc/pdf/openocd.pdf). I've read the section and observed the following example:

# openocd.cfg file
# -----------------
    source [find interface/olimex-arm-usb-tiny-h.cfg]
    reset_config trst_and_srst
    jtag_rclk 8

Because my chip connects through the STLink probe and uses SWD transport protocol (instead of JTAG), I made a few modifications to the example:

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

I connect a NUCLEO_F303K8 board to my PC for this test. Then I issue the following command in my console:

OpenOCD outputs the following and then terminates:

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

So I end up with a few questions concerning autoprobing.

 

3. My questions

Question 1:
Is "Autoprobing" (as described in Section 10.7) really what I need here? If the answer is No, please ignore the next questions.

Question 2:
I've tried to imitate the example given in Section 10.7, with some minor modifications to make the example suitable for my Nucleo board. Unfortunately the Autoprobing fails. Is this because OpenOCD doesn't support autoprobing with the SWD protocol? Or am I simply making a mistake in my .cfg file?

Question 3:
I noticed that the Autoprobing example from Section 10.7 configures the reset behaviour of OpenOCD. Does this mean that Autoprobing will always be "intrusive" in the sense that it resets the chip?

Question 4:
The Autoprobing example from Section 10.7 seems to bring OpenOCD into the server state anyhow. Is it possible to avoid that? I want to keep this "chip detection" thing simple, without the need for a Telnet or GDB client.


EDITS

Thank you @nattgris for your remarkable answer. I've got a few more practical questions though.

1. With ST-Link

Suppose we're using the ST-Link, despite its sub-optimal cooperation with OpenOCD. You said:

How do I practically persuade the ST-Link to do that? In other words, what should I put in my openocd.cfg file to achieve this?

 

2. With SWD-probe (but not ST-Link)

Suppose we're using a true SWD-probe. You said:

From this, I conclude that:

  1. Autoprobing as described in Section 10.7 is only applicable on JTAG, not on SWD.

  2. As Autoprobing is not available for SWD, the alternative approach is to simply connect to the chip, after which OpenOCD automatically prints the DPIDR register. This DPIDR register is the SWD-equivalent of the JTAG TAP IDCODE, so to speak, and can identify the chip to some extent.
    But how does one simply connect to the chip, if one doesn't know what chip is attached to the PC in the first place? If I'm not mistaken, OpenOCD always needs the specific config file, like stm32f7x.cfg, stm32f4x.cfg, stm32l0.cfg, ... to connect to the chip.

  3. Apparently, the JTAG IDCODE and the SWD-equivalent DPIDR register provide the chip designer, which would always be "ARM" for the ARM-Cortex chips. This is not enough for complete chip identification. However, you say that ARM-chips have separate boundary scan TAPs providing further IDCODE registers for more complete identification. Unfortunately, these are JTAG-only. This means that SWD is on a dead-end here in terms of chip identification?

  4. Autoprobing with JTAG (and therefore reading the IDCODE reg) can be completely non-intrusive. Therefore, one can make the system reset signal unavailable:
    reset_config none
    You say that reading the DPIDR over SWD (which I consider to be the SWD-equivalent of JTAG autoprobing) is also non-intrusive. Could I also enforce that "non-intrusiveness" by making the reset signal unavailable?

 

3. With JTAG-probe (but not ST-Link)

The JTAG protocol seems to provide the best support for chip identification (using Autoprobing). My conclusions:

  1. The Autoprobing described in Section 10.7 would print the TAP IDCODE from the chip. For ARM-chips that would simply print "ARM", not the actual manufacturer (like "ST") and the chip name (like "STM32F767ZI").

  2. How do I practically make sure that the procedure also prints these further info's, more in particular the actual chip name? In other words, what should I put in my openocd.cfg file (and possibly the openocd startup command) to achieve this?

 
Thank you very much :-)

解决方案

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.

这篇关于如何使用OpenOCD ping芯片(检测是否连接了芯片)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

07-22 19:23
查看更多