Main Page | Recent changes | Edit this page | Version history |

Printable version

131.246.51.18 (Talk)
Log in | Help
 

OpenOCD configuration

OpenFacts, the Open Source Knowledge Database

The Open On-Chip Debugger (OpenOCD) runs as a daemon, and reads it current configuration by default from the file openocd.cfg in the current directory. A different configuration file can be specified with the -f <conf.file> given at the openocd command line.

The configuration file is used to specify on which ports the daemon listens for new connections, the JTAG interface used to connect to the target, the layout of the JTAG chain, the targets that should be debugged, and connected flashes.

Daemon configuration

telnet_port <number>
Port on which to listen for incoming telnet connections
gdb_port <number>
First port on which to listen for incoming GDB connections. The GDB port for the first target will be gdb_port, the second target will listen on gdb_port + 1, and so on.

daemon_startup <'attach'|'reset'>
Tells the OpenOCD whether it should reset the target when the daemon is launched, or if it should just attach to the target.

JTAG interface configuration

interface <name>
Use the interface driver <name> to connect to the target. Currently supported interfaces are
jtag_speed <number>
Limit the maximum speed of the JTAG interface. Usually, a value of zero means maximum speed. The actual effect of this option depends on the JTAG interface used.
reset_config <signals> [combination]
The configuration of the reset signals available on the JTAG interface AND the target. If the JTAG interface provides SRST, but the target doesn't connect that signal properly, the OpenOCD can't use it. <signals> can be 'none', 'trst_only', 'srst_only' or 'trst_and_srst'. [combination] is an optional value specifying broken reset signal implementations. 'srst_pulls_trst' states that the testlogic is reset together with the reset of the system (e.g. Philips LPC2000, "broken" board layout), 'trst_pulls_srst' says that the system is reset together with the test logic (only hypothetical, I haven't seen hardware with such a bug, and can be worked around)
jtag_device <IR length> <IR capture> <IR mask> <IDCODE instruction>
Describes the devices that form the JTAG daisy chain, with the first device being the one closest to TDO. The parameters are the length of the instruction register (4 for all ARM7/9s), the value captured during Capture-IR (0x1 for ARM7/9), and a mask of bits that should be validated when doing IR scans (all four bits (0xf) for ARM7/9). The IDCODE instruction will in future be used to query devices for their JTAG identification code. This line is the same for all ARM7 and ARM9 devices. Other devices, like CPLDs, require different parameters. An example configuration line for a Xilinx XC9500 CPLD would look like this:
jtag_device 8 0x01 0x0e3 0xfeThe instruction register (IR) is 8 bits long, during Capture-IR 0x01 is loaded into the IR, but only bits 0-1 and 5-7 should be checked, the others (2-4) might vary. The IDCODE instruction is 0xfe.

parport options

parport_port <number>
Either the address of the I/O port (default: 0x378 for LPT1) or the number of the /dev/parport device
parport_cable <name>
The layout of the parallel port cable used to connect to the target. Currently supported cables are

amt_jtagaccel options

parport_port <number>
Either the address of the I/O port (default: 0x378 for LPT1) or the number of the /dev/parport device

ftdi2232 options

ftdi2232_vid_pid <vid> <pid>
The vendor ID and product ID of the FTDI FT2232 device. If not specified, the FTDI default values are used.

ftd2xx options

ftd2xx_device_desc <description>
The USB device description of the FTDI FT2232 device. If not specified, the FTDI default value is used.
ftd2xx_layout <name>
The layout of the FT2232 GPIO signals used to control output-enables and reset signals.
ftd2xx_vid_pid <vid> <pid>
The vendor ID and product ID of the FTDI FT2232 device. If not specified, the FTDI default values are used. This command is only available on Linux.

ep93xx options

Currently, there are no options available for the ep93xx interface.

Target configuration

target <type> <endianess> <reset_mode>
Defines a target that should be debugged. Currently supported types are:
Endianess may be 'little' or 'big', though this isn't fully implemented at this time (SVN revision 50). The reset_mode specifies what should happen to the target when a reset occurs:

arm7tdmi options

target arm7tdmi <endianess> <reset_mode> <jtag#> [variant]
The arm7tdmi target definition requires at least one additional argument, specifying the position of the target in the JTAG daisy-chain. The first JTAG device is number 0. The [variant] is an optional parameter specifying the actual type of arm7tdmi core. Currently, this allows 'arm7tdmi-s_r4' or 'arm7tdmi_r4' to be specified. In future versions this might allow use of the monitor debug mode available on these cores.

arm720t options

ARM720t options are similar to ARM7TDMI options.

arm9tdmi options

ARM9TDMI options are similar to ARM7TDMI options. Supported variants are 'arm920t', 'arm922t' and 'arm940t'. This enables the hardware single-stepping support found on these cores.

arm920t options

ARM920t options are similar to ARM9TDMI options.

Flash configuration

flash bank <driver> <base> <size> <chip_width> <bus_width> [driver_options ...]
Configures a flash bank at <base> of <size> bytes and <chip_width> and <bus_width> bytes using the selected flash <driver>.

lpc2000 options

flash bank lpc2000 <base> <size> 0 0 <variant> <target#> <clock> ['calc_checksum']
LPC flashes don't require the chip and bus width to be specified. Additional parameters are the <variant>, which may be 'lpc2000_v1' (all but 213x and 214x) or 'lpc2000_v2' (213x and 214x), the number of the target this flash belongs to (first is 0), the frequency at which the core is currently running (in kHz), and the optional keyword 'calc_checksum', telling the driver to calculate a valid checksum for the exception vector table.

cfi options

flash bank cfi <base> <size> <chip_width> <bus_width> <target#> [working_area] [working_area_size]
CFI flashes take the number of the target they're connected to, and the base address and size of an optional working area to significantly speed up flash programing operations.

TODO: at91sam7 options

This page has been written as part of the Open On-Chip Debugger project.


[Main Page]

Main Page
Recent changes
Random page
Questions and suggestions
Current events


Edit this page
Discuss this page
Version history
What links here
Related changes
Special pages
OpenFacts bug reports