Yes: Many C2000 MCU boards have a JTAG debug
probe implemented on the PCB. Unless there is an application
requirement, TI suggests using the on-board debug probe for development
purposes. The XDS100 and the XDS110 are two target debug probes that are
found on TI C2000 Evaluation Modules (EVMs).
No: If a stand-alone debug probe is used, where
the board design is custom, the implementation of the JTAG header and
passives need to be verified before continuing the debug process. The
device-specific data sheet contains the reference schematic for the
proper pull-up/pull-down values to ensure proper behavior. If the PCB is
manufactured by TI, this step can be skipped.
Power Good LED On: This step is meant to verify that the
target is powered correctly from a power source without the use of any external
equipment like a volt meter. All of TI C2000 development boards have LED(s) to
indicate power is being supplied to the MCU. Other LEDs can be used to indicate
some out-of-box code is successfully running. For the location and function of
these LEDs, consult the device-specific user's guide for the EVM under
debug.
Replace Cables: If the Power
Good LEDs are not observed, there is likely a problem with the power source
supplied to the EVM. Many TI EVMs use the USB connection not only to provide a
debug path from the host to the target, but also use the 5 V from the USB to
power the EVM. A simple check can be to change the USB cable to ensure this is
not the issue. If there is insufficient power from the host, a powered USB hub
can help as well.
Switch to an External Power Supply: If the on-board
power supply of the TI built board is not providing power at the appropriate
level and the USB cables are known good, it may be possible to switch to an
external power supply for the EVM. To understand if this is supported, see the
device-specific user's guide for your EVM. In this case, some probing of the
voltages on the board is necessary to determine if the power supply is the issue
or something on the PCB is inhibiting the voltage to the MCU.
Present in Device Manger: For the JTAG debug probe to
communicate to the PC, the driver files need to be installed. This typically
occurs co-incident to the installation of the Code Composer Studio (CCS). To
verify that the drivers are successfully installed, connect the PC to the JTAG
debug probe and power up. Then go to Control Panel → Device Manager (Figure 5-1) and locate the associated debug probe.
Figure 5-1 Windows 10™
Device Manager Showing Successful Detection of XDS110 Debug
Probe
Reprogram Emulation Controller: This step ensures that
the device that functions as the emulation controller has the correct firmware.
Install Device Driver: Another possible reason for the
debug probe not showing up in the host PC/MAC system is the driver is not
installed. Typically this occurs with the installation of CCS, but consult the
debug probe product page for possible drivers.
Is TRSTn Signal High At the MCU: This step is checking
for a certain behavior when CCS is trying to connect to the target. One of the
first actions is that Test Reset (TRSTn) will go inactive high, activating the
core debug connection to the external debug probe. If TRSTn does not change
state during a CCS Connect Target operation, then the debug probe needs to be
checked for proper configuration correctly both at the device level and inside
the host's operating system.
Check Target Configuration: The
Target Configuration File (.ccxml) contains the information necessary to connect
to your target device and the JTAG debug probe being used. To view the current
target configurations, select Target Configurations (Figure 5-2) under the "View" tab in CCS. Double click on the .ccxml corresponding to the
target that is being debugged. If the drivers for the debug probe are installed
correctly and the correct options are selected, the Test Connections button (
Figure 5-3 ) should be available and ready to execute. The datalog from this test can
assist in isolating the cause for the connection issues, do not skip this step.
Note that many example projects are installed as part of C2000Ware or
controlSuite have a "target configs" folder. This has a .ccxml file pre-created
based on a an assumption of a default EVM and debugger. This file is used when
the "Debug" icon is used to launch the debug session. If the "Debug" button is
the desired method to launch the debug session, the .ccxml in "target configs"
need to be modified.
Figure 5-2 Target Configurations
View
Figure 5-3 Test
Connections
Modify the CCS "On Connect"
Action: There are two ways to launch the debug session from CCS. One way
is to right click the desired target configuration from the previous step and
select "Launch Selected Configuration". Once this is done the target CPU can be
connected by right clicking on the CPU core(s) and select "Connect Target". The
other way is to use the Debug Button (Figure 5-4), which not only launches the configuration, but also connects, loads the
target program file into memory, and executes to "main". These settings can be
modified but this is the default operation. The default actions can be modified
by either right clicking on the .ccxml file being used or selecting "Debug
Options" from the arrow dropdown next to the Debug button and changing the auto
run and launch options in the Target sub-menu. During the troubleshooting phase
of this document, it is recommended to use the former method of "Connect
Target". This helps to isolate any issues that are not purely JTAG related, but
caused by code execution or other system interactions. Once the system is
verified to be stable for launching and connecting the target, use the Debug
button to handle these steps.
Figure 5-4 Code Composer "Debug"
Button
XRSn State: Looking at XRSn on an oscilloscope, XRSn
should be inactive high when the device is operational. If XRSn is low or
pulsing from low to high to low, it could indicate one of several issues. If the
pulses are periodic, it is likely the watchdog (WD) on the MCU that is causing
the reset because it is not being serviced or is not disabled. This toggle
behaivor is not in itself a bad thing, as it indicates that the MCU is powering
up, and executing code, but this can cause instability in the debug flow. If
there is non-determinate pulsing or XRSn is always low, it could indicate that
the internal Brown Out Reset (BOR) is being triggered due to a supply voltage
issue or some issue on the PCB itself. Note that this is different than the
static supply checks mentioned earlier. Both of these potential issues can also
happen during code execution. They can either disconnect the debug session or
prevent it from reliably connecting.
Change BootMode: Check the hardware files to ensure
BootMode pins are in the correct state for the mode expected. If the XRSn pin
shows the behavior mentioned above, or if the state of the Flash memory is
unknown, going into Wait Boot Mode will put the device into a safe state
allowing for reads of memory and registers. For more details on the boot pins
and the selection required for Wait Boot Mode, check the Boot section of
the device-specific data sheet.
"Debug State Lost" CCS Message: Even if XRSn is in the
desired inactive high state, there still can be issues that prevent or end the
debug connection. Often this behavior is related to the code that is executing
on the device. For this reason it is also advisable to but the device in Wait
Boot Mode.
Check VREG Setting: Any voltage supplied to the device
outside the recommended operating conditions can cause a brown out reset (BOR)
event to occur. In these situations, it can be helpful to measure the voltage
rails of the device. Using the schematic files located in either C2000Ware or controlSuite, the probe points for the rails of the
device can be verified. If this issue is happening during code execution, there
can be an issue with the amount of current the source can provide to the device.
If the EVM under debug is a TI manufactured device, any rails generated from the
external supply should by design be OK, and at this point the checks are being
done to verify the board integrity is good.
Check Clocks (JTAG Clock/System Clock): Measure and
confirm the JTAG clock and crystal or external clock source are as per data
sheet defined levels. Check the manufacturer’s data sheet for the debug probe.
This is the final step to ensure that the device is supplied with the inputs it
needs to function correctly. Many Piccolo™ class devices
have a built in, zero pin oscillator. It can be helpful to use this as the
functional clock in case of external clock uncertainty. For the available clock
sources and their tolerances, see the device-specific data sheet. While the JTAG
clock is typically maintained at its default speed from the initial setup file,
it can be helpful to slow down the clock rate to see if this improves the
initial connection or connection stability. This may be especially helpful on
custom designed PCBs.
Second Device Check: If after all the above steps do not
fix the issue, it is possible a second PCB/EVM can be used to determine whether
the issue is local to one EVM. If a second device fails in the same manner there
is likely either a setup issue or issue external to the EVM at play.
Disconnecting During\After Run:
If a device is password locked, the Emulation Code Security Logic (ECSL) in the
Code Security Module (CSM) disables JTAG emulation to the device, resulting in
JTAG connection issues. This can occur before connection per above, but can also
occur during debug if a secure region of memory is accessed while the debugger
is connected. While Wait Boot Mode allows connections, it will not correct the
issue of access to secure memory while debugging. In order to correct this, the
CSM must be unlocked through use of a known password. For locking and unlocking
a device, see the device specific data sheet on the CSM module and the
associated steps. If the password is unknown, it will not be possible to unlock
the device. Debug will be limited to unsecured regions.
Post question on E2E.ti.com: If, at the end of this
flow, there are still issues connecting or maintaining connection with the
device through JTAG, it is encouraged to post your questions or issues to our
TI C2000 Engineer To Engineer Forum. When posting,
please provide the following information in addition to your issue:
Subject/Title of the Post: "JTAG Connectivity Issue -
(Insert Part Number here)
CCS Version
Debug Probe Used
Type of target: TI made EVM or custom
Confirmation of which steps in this guide were
taken
Custom board schematics of the JTAG connection, if
possible, if not a TI EVM