<!-- Start of markdown source --> #Introduction Code Composer Studio and the XDS Debug Probes can control the device including issuing specific reset commands. #The nTRST pin The nTRST pin is the Debug/Emulation logic reset for the device and is an optional pin per the JTAG 1149.1 standard, but it is supported on selected TI devices such as the C2000 MCUs. This signal 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 normally. This pin is normally pulled-down internally within the device, thus keeping this signal asserted when a Debug Probe is not connected. When JTAG access is required, either in [BSDL](emu_bsdl.html) or Debug modes, the nTRST signal is de-asserted (driven inactive) by an external Emulator/DTC (Debug-Test-Controller). If the target device/board supports Boundary-scan, then the Boundary Scan controller must support de-asserting nTRST or the board design must provide for manual pull up of this signal. During rare circumstances, a device's Debug/Emulation logic can be put in a state that requires a nTRST signal to be asserted. This is usually required when there is a lack of responsiveness of the Debug Probe or sequences of errors such as target timeouts or the inability to halt a core or device, and the causes vary greatly, ranging from invalid configuration files to electrical issues such as ground loops or noise. The most common cases of the debugger generating timeout errors on an operation request are caused by the execution of illegal opcodes or a (ready) RDY- signal hang (internal or external). Typically a RDY- hang (or ready-hang) is caused by a peripheral (either internal or external to the device) hanging the RDY- signal on a memory access. In both cases (illegal opcodes and RDY hang) the core's pipeline cannot advance, which causes a Debug timeout error. In most devices, if the pipeline does not advance the debug logic is also kept stalled permanently. Generally this problem can be cleared with a hard device reset, but occasionally nTRST is also required. RDY- hangs can occur on both ARM cores and TI processors, 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. A thorough explanation of various connection errors can be found at the [Debugging JTAG](../ccs_debugging_jtag_connectivity_issues.html) page. #The nRESET pin nRESET (sometimes called SRST) is the System Reset signal and is supported by all modern XDS Debug Probes. It provides a mechanism for remotely resetting your entire system if the nReset signal from the emulation header is integrated into your applications power-up-reset hardware. - It requires the use of a 20-pin or 60-pin [JTAG connector](emu_jtag_connectors.html). - For some devices, when debugging boot code the [Wait in Reset](emu_wait_in_reset.html) may use this signal. - XDS products that don't support this feature are generally only capable of resetting the TI devices on the scan chain, either via the nTRST signal or via the [ICEPICK](emu_icepick.html). #CCS Reset Types ##System Reset This reset will typically reset the the entire device by asserting the nRESET signal. In general this signal is tied to PMIC devices that perform a warm or power on reset on the entire board. Frequently this reset disconnects the JTAG connection as the device is power cycled. ##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. The CPU Reset usually does not affect peripherals and external devices and preserves the contents of its RAM memory. Keep this in mind when trying to recover from a problem on the board, given that any misconfigurations or data corruptions will still be present after the device starts execution again. As an example, a CPU Reset on a typical C64x+ core causes the following 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 This resets the XDS and asserts the nTRST signal, so the debug logic on chip is also reset. This command is only active when all cores of the device are disconnected. ##Automatic Reset Issuing a reset can be done automatically in a CCS Debug session by using one of the methods: - GEL APIs GEL_Reset() or GEL_AdvancedReset(). Check section 7.9 of the [CCS User's Guide](../users_guide/index.html) - Changing the Program/Memory Load options in CCS. Check section 7.2.4 of the [CCS User's Guide](../users_guide/index.html) #Asserting reset via command line The reset command can be asserted directly via command line when a XDS Debug Probe is connected to a target board. This is useful for scripting. The most generic method uses the DBGJTAG utility, which works for all XDS Debug Probes. [[b Note: The **-f @xds110** in the dbgjtag commands below can also be replaced by other Debug Probe designators such as: - **-f @xds200** for XDS200-class Debug Probes - **-X emulator,driver=bh560v2u** for XDS560v2 USB from Blackhawk (use bh560v2e for Ethernet) - **-X emulator,driver=sd560v2u** for XDS560v2 USB from Spectrum Digital (use sd560v2e for Ethernet) ]] ##XDS Reset The following dbgjtag command will reset the XDS and drive nTRST active, so the debug logic on chip is also reset. ```bash C:\ti\ccs1010\ccs\ccs_base\common\uscif> dbgjtag -f @xds110 -Y reset,jtag=1 ``` ##nRESET The following dbgjtag command will reset the XDS and drive the System Reset signal. This reset has no effect on the Emulator or on-chip emulation logic. To assert the signal: ```bash C:\ti\ccs1010\ccs\ccs_base\common\uscif> dbgjtag -f @xds110 -Y reset,system=0 ``` To de-assert the signal: ```bash C:\ti\ccs1010\ccs\ccs_base\common\uscif> dbgjtag -f @xds110 -Y reset,system=1 ``` [[b Note about XDS110: The [XDS110](emu_xds110.html) also has its own utility to issue a reset signal named &lt;xds110reset.exe&gt;. Check section 3.7.3.1 of its User's Guide [SPRUI94](https://www.ti.com/lit/ug/sprui94/sprui94.pdf) ]] <hr> <!-- ===Q: How can I test just the ARM926 scan path? === *A: Use "dbgjtag -f <CCS Path>\ccboard0.dat -S pathlength -R routelist,devices=<arm9_0>" where <CCS Path> is your CCS installation path and directory for the CCBoard0.dat file and <arm9_0> is the name of the [[ICEpick]] scan path for the ARM926. This will have ICEpick add just the ARM9 to the path and test it. It should return "JTAG IR instruction path length is 28 bits", "JTAG DR bypass path-length is 5 bits". Take note of any errors reported by the tool that conflicts with that message. --> <!-- End of markdown source --> <div id="footer"></div>