Every system configuration may require a different reset configuration. This can also be quite confusing. Please see the various board files for example.
How long (in milliseconds) OpenOCD should wait after deasserting nSRST before starting new JTAG operations.
Same jtag_nsrst_delay, but for nTRST
The jtag_n[st]rst_delay options are useful if reset circuitry (like a big resistor/capacitor, reset supervisor, or on-chip features). This keeps the signal asserted for some time after the external reset got deasserted.
Note: To maintainer types and integrators. Where exactly the “reset configuration” goes is a good question. It touches several things at once. In the end, if you have a board file - the board file should define it and assume 100% that the DONGLE supports anything. However, that does not mean the target should not also make not of something the silicon vendor has done inside the chip. Grr.... nothing is every pretty.
OpenOCD defines these signals in these terms:
[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). combined imples both srst_pulls_trst and trst_pulls_srst. The default behaviour if no option given is separate.
The [trst_type] and [srst_type] parameters allow the driver type of the reset lines to be specified. Possible values are trst_push_pull (default) and trst_open_drain for the test reset signal, and srst_open_drain (default) and srst_push_pull for the system reset. These values only affect JTAG interfaces with support for different drivers, like the Amontec JTAGkey and JTAGAccelerator.