如何使用 OpenOCD ping 芯片(检测芯片是否连接) [英] How to ping a chip (detect if a chip is connected) with OpenOCD

问题描述

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:

1. Start OpenOCD with the probe config file (eg. stlink.cfg ) given as -f parameter. So OpenOCD knows what probe to use, but doesn't know what chip it will find.

2. OpenOCD detects a chip and reports this somehow (eg. write something to stdout). If possible, this action should not be intrusive to the chip (like resetting it).

3. OpenOCD shuts down.

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 -s "C:...scripts" -f "C:...openocd.cfg"

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:

.. 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.

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:

Autoprobing, as described in Section 10.7, is only relevant for JTAG [...]. 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. [...]
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.

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 芯片(检测芯片是否连接)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！