Every system configuration may require a different reset configuration. This can also be quite confusing. Resets also interact with reset-init event handlers, which do things like setting up clocks and DRAM, and JTAG clock rates. (See JTAG Speed.) They can also interact with JTAG routers. Please see the various board files for examples.
Note: To maintainers and integrators: Reset configuration touches several things at once. Normally the board configuration file should define it and assume that the JTAG adapter supports everything that's wired up to the board's JTAG connector.However, the target configuration file could also make note of something the silicon vendor has done inside the chip, which will be true for most (or all) boards using that chip. And when the JTAG adapter doesn't support everything, the user configuration file will need to override parts of the reset configuration provided by other files.
There are many kinds of reset possible through JTAG, but they may not all work with a given board and adapter. That's part of why reset configuration can be error prone.
In the best case, OpenOCD can hold SRST, then reset the TAPs via TRST and send commands through JTAG to halt the CPU at the reset vector before the 1st instruction is executed. Then when it finally releases the SRST signal, the system is halted under debugger control before any code has executed. This is the behavior required to support the reset halt and reset init commands; after reset init a board-specific script might do things like setting up DRAM. (See Reset Command.)
Because SRST and TRST are hardware signals, they can have a variety of system-specific constraints. Some of the most common issues are:
There can also be other issues. Some devices don't fully conform to the JTAG specifications. Trivial system-specific differences are common, such as SRST and TRST using slightly different names. There are also vendors who distribute key JTAG documentation for their chips only to developers who have signed a Non-Disclosure Agreement (NDA).
Sometimes there are chip-specific extensions like a requirement to use the normally-optional TRST signal (precluding use of JTAG adapters which don't pass TRST through), or needing extra steps to complete a TAP reset.
In short, SRST and especially TRST handling may be very finicky, needing to cope with both architecture and board specific constraints.
How long (in milliseconds) OpenOCD should wait after deasserting nSRST (active-low system reset) before starting new JTAG operations. When a board has a reset button connected to SRST line it will probably have hardware debouncing, implying you should use this.
How long (in milliseconds) OpenOCD should wait after deasserting nTRST (active-low JTAG TAP reset) before starting new JTAG operations.
This command tells OpenOCD the reset configuration of your combination of JTAG board and target in target configuration scripts.
Information earlier in this section describes the kind of problems the command is intended to address (see SRST and TRST Issues). As a rule this command belongs only in board config files, describing issues like board doesn't connect TRST; or in user config files, addressing limitations derived from a particular combination of interface and board. (An unlikely example would be using a TRST-only adapter with a board that only wires up SRST.)
The mode_flag options can be specified in any order, but only one of each type – signals, combination, trst_type, and srst_type – may be specified at a time. If you don't provide a new value for a given type, its previous value (perhaps the default) is unchanged. For example, this means that you don't need to say anything at all about TRST just to declare that if the JTAG adapter should want to drive SRST, it must explicitly be driven high (srst_push_pull).
signals can specify which of the reset signals are connected. For example, If the JTAG interface provides SRST, but the board doesn't connect that signal properly, then OpenOCD can't use it. Possible values are none (the default), trst_only, srst_only and trst_and_srst.
Tip: If your board provides SRST or TRST through the JTAG connector, you must declare that or else those signals will not be used.The combination is an optional value specifying broken reset signal implementations. The default behaviour if no option given is separate, indicating everything behaves normally. srst_pulls_trst states that the test logic 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). combined implies both srst_pulls_trst and trst_pulls_srst.
The optional trst_type and srst_type parameters allow the driver mode of each reset line to be specified. These values only affect JTAG interfaces with support for different driver modes, like the Amontec JTAGkey and JTAGAccelerator. Also, they are necessarily ignored if the relevant signal (TRST or SRST) is not connected.
Possible trst_type driver modes for the test reset signal (TRST) are trst_push_pull (default) and trst_open_drain. Most boards connect this signal to a pulldown, so the JTAG TAPs never leave reset unless they are hooked up to a JTAG adapter.
Possible srst_type driver modes for the system reset signal (SRST) are the default srst_open_drain, and srst_push_pull. Most boards connect this signal to a pullup, and allow the signal to be pulled low by various events including system powerup and pressing a reset button.