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
- parport: PC parallel port bit-banging (Wigglers, PLD download cable, ...)
- amt_jtagaccel: Amontec Chameleon in its JTAG Accelerator configuration connected to a PC's EPP mode parallel port
- ftdi2232: FTDI FT2232 based devices using the open-source libftdi (Currently only supported on Linux)
- ftd2xx: FTDI FT2232 based devices using the binary only FTD2XX driver (Supported on both Windows and Linux)
- ep93xx: Cirrus Logic EP93xx based single-board computer bit-banging (in development)
- 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:
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
- wiggler: Original Wiggler layout, also supported by several clones, such as the Olimex ARM-JTAG
- old_amt_wiggler: The Wiggler configuration that comes with Amontec's Chameleon Programmer. The new version available from the website uses the original Wiggler layout ('wiggler')
- chameleon: Describes the connection of the Amontec Chameleon's CPLD when operated in configuration mode. This is only used to program the Chameleon itself, not a connected target.
- dlc5: Xilinx Parallel cable III.
- triton: The parallel port adapter found on the Karo Triton 1 Development Board.
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:
- arm7tdmi
- arm720t
- arm9tdmi
- arm920t
- reset_halt: Immediately request a target halt after reset. This allows targets to be debugged from the very first instruction. This is only possible with targets and JTAG interfaces that correctly implement the reset signals.
- reset_init: Similar to 'reset_halt', but executes the script file defined to handle the 'reset' event for the target. Like 'reset_halt' this only works with correct reset implementations.
- reset_run: Simply let the target run after a reset.
- run_and_halt: Let the target run for some time (default: 1s), and then request halt.
- run_and_init: A combination of 'reset_init' and 'run_and_halt'. The target is allowed to run for some time, then halted, and the 'reset' event script is executed.
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.