Emulation Resets

TRST- Pin: This is the JTAG 1139.1 and Debug/Emulation logic reset for the device. TRST- is an optional pin per the JTAG 1139.1 standard, but it’s typically supported on TI devices. This pin is normally pulled-down internally within the device (See the Target Connection Guide for recommendations and conditions where an external pull–down may be required) When an Emulator target cable is not connected the pull-down holds the device in the TRST- state permanently. An active TRST- initializes the JTAG state machine to the TLR (Test-Logic-Reset) state, and holds the Debug/Emulation logic in the device in reset allowing the device to operate in it’s normal mode. Normally, the only time TRST is released (driven inactive) is by an external Emulator/DTC(Debug-Test-Controller). If your target card supports Boundary Scan, then your Boundary Scan controller must support driving TRST- inactive or you must include a provision on your target board to pull-up TRST- during boundary scan operations.

During rare circumstances a device’s Debug/Emulation logic can get in a state that requires a TRST- (see Emulator Reset). A symptom of this may be the Debugger has become non-responsive or emulation errors occur, like target timeout or error halting, immediately at connection time (although this can also be caused by invalid CCS configuration files) Generally this state is caused by electrical issues (reflections on TCK or TDO) between the target header and the device, but it can also be caused by other factors.

The most common cases of the debugger generating timeout errors on an operation request is caused by the execution of illegal opcodes or a RDY- signal hang (internal or external). Typically a RDY- hang is caused by a peripheral (either internal or external to the device) hanging RDY- on a memory access. In both cases (illegal opcodes and RDY hang) the core’s pipeline can not advance which cases the Debug/Emulator timeout error. In most devices if the pipeline will not advance the debug logic will also stall permanently. Generally this problem can be cleared with a hard device reset, but occasionally TRST- is also required.

RDY- hangs can occur on both ARM cores and TI DSPs, although most modern cores now provide mechanisms to allow visibility to registers during a RDY hang condition. Typically the RDY signal is forced inactive to allow the debug operation to complete. The condition that caused the original RDY hang must be cleared for the core to operate normally again.

CCS Reset Types:

System Reset – This reset will typically reset the the entire device. In multi-core devices all cores are reset.

CPU Reset – Typically isolated to reset just the core, not the entire device. In multi-core devices typically isolated to a single core. In devices that support a software reset, a CCS Reset may be equivalent.

For C64x+ cores a CCS CPU Reset effects:

• Local CPU reset
• CPU control registers reset
• L1/L2 caches invalidated
• Outstanding read/write commands completed and are discarded by the CPU.
• IDMA reset
• Does not change memory configuration or control registers
• Does not touch clocks
• Does not corrupt memory

Reset Emulator – Will reset the XDS and drive TRST- active, so the debug logic on chip is also reset. To make this command active the device must be disconnected by CCS.

dbgjtag Reset Types:

XDS Reset - The following dbgjtag command will reset the XDS and drive TRST- active, so the debug logic on chip is also reset.

dbgjtag -d xds.out -p0 -rv

where xds.out is specific to your XDS.

nRESET- Pin – Requires 20-pin or MIPI 60-pin target XDS header on your card with the header’s nRESET- signal integrated into the target’s system reset controller. The nRESET- signal can be driven active for 500usec using the following dbgjtag command. This reset has no effect on the Emulator or on-chip emulation logic.

dbgjtag -d xds.out -p0 -Y system,signal=pulse

where xds.out is specific to your XDS.