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.
Minimum amount of time (in milliseconds) OpenOCD should wait after asserting nSRST (active-low system reset) before allowing it to be deasserted.
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.
Minimum amount of time (in milliseconds) OpenOCD should wait after asserting nTRST (active-low JTAG TAP reset) before allowing it to be deasserted.
How long (in milliseconds) OpenOCD should wait after deasserting nTRST (active-low JTAG TAP reset) before starting new JTAG operations.
This command displays or modifies 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, gates, trst_type, srst_type and connect_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 and/or TRST through the JTAG connector, you must declare that so those signals can 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. NXP 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 gates tokens control flags that describe some cases where JTAG may be unvailable during reset. srst_gates_jtag (default) indicates that asserting SRST gates the JTAG clock. This means that no communication can happen on JTAG while SRST is asserted. Its converse is srst_nogate, indicating that JTAG commands can safely be issued while SRST is active.
- The connect_type tokens control flags that describe some cases where SRST is asserted while connecting to the target. srst_nogate is required to use this option. connect_deassert_srst (default) indicates that SRST will not be asserted while connecting to the target. Its converse is connect_assert_srst, indicating that SRST will be asserted before any target connection. Only some targets support this feature, STM32 and STR9 are examples. This feature is useful if you are unable to connect to your target due to incorrect options byte config or illegal program execution.
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 JTAG Accelerator. 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 the default trst_push_pull, 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.
OpenOCD has several ways to help support the various reset mechanisms provided by chip and board vendors. The commands shown in the previous section give standard parameters. There are also event handlers associated with TAPs or Targets. Those handlers are Tcl procedures you can provide, which are invoked at particular points in the reset sequence.
When SRST is not an option you must set
up a reset-assert event handler for your target.
For example, some JTAG adapters don't include the SRST signal;
and some boards have multiple targets, and you won't always
want to reset everything at once.
After configuring those mechanisms, you might still find your board doesn't start up or reset correctly. For example, maybe it needs a slightly different sequence of SRST and/or TRST manipulations, because of quirks that the reset_config mechanism doesn't address; or asserting both might trigger a stronger reset, which needs special attention.
Experiment with lower level operations, such as jtag_reset and the jtag arp_* operations shown here, to find a sequence of operations that works. See JTAG Commands. When you find a working sequence, it can be used to override jtag_init, which fires during OpenOCD startup (see Configuration Stage); or init_reset, which fires during reset processing.
You might also want to provide some project-specific reset schemes. For example, on a multi-target board the standard reset command would reset all targets, but you may need the ability to reset only one target at time and thus want to avoid using the board-wide SRST signal.
This is invoked near the beginning of the reset command, usually to provide as much of a cold (power-up) reset as practical. By default it is also invoked from jtag_init if the scan chain does not respond to pure JTAG operations. The mode parameter is the parameter given to the low level reset command (halt, init, or run), setup, or potentially some other value.
The default implementation just invokes jtag arp_init-reset. Replacements will normally build on low level JTAG operations such as jtag_reset. Operations here must not address individual TAPs (or their associated targets) until the JTAG scan chain has first been verified to work.
Implementations must have verified the JTAG scan chain before they return. This is done by calling jtag arp_init (or jtag arp_init-reset).
This validates the scan chain using just the four standard JTAG signals (TMS, TCK, TDI, TDO). It starts by issuing a JTAG-only reset. Then it performs checks to verify that the scan chain configuration matches the TAPs it can observe. Those checks include checking IDCODE values for each active TAP, and verifying the length of their instruction registers using TAP
-ircaptureand-irmaskvalues. If these tests all pass, TAPsetupevents are issued to all TAPs with handlers for that event.