SPRACF0C May   2018  – August 2024 TMS320C28341 , TMS320C28342 , TMS320C28343 , TMS320C28343-Q1 , TMS320C28344 , TMS320C28345 , TMS320C28346 , TMS320C28346-Q1 , TMS320F280021 , TMS320F280021-Q1 , TMS320F280023 , TMS320F280023-Q1 , TMS320F280023C , TMS320F280025 , TMS320F280025-Q1 , TMS320F280025C , TMS320F280025C-Q1 , TMS320F280040-Q1 , TMS320F280040C-Q1 , TMS320F280041 , TMS320F280041-Q1 , TMS320F280041C , TMS320F280041C-Q1 , TMS320F280045 , TMS320F280048-Q1 , TMS320F280048C-Q1 , TMS320F280049 , TMS320F280049-Q1 , TMS320F280049C , TMS320F280049C-Q1 , TMS320F2802-Q1 , TMS320F28020 , TMS320F28021 , TMS320F28022 , TMS320F28022-Q1 , TMS320F28023 , TMS320F28023-Q1 , TMS320F28026 , TMS320F28026-Q1 , TMS320F28026F , TMS320F28027 , TMS320F28027-Q1 , TMS320F28027F , TMS320F28027F-Q1 , TMS320F28030 , TMS320F28030-Q1 , TMS320F28031 , TMS320F28031-Q1 , TMS320F28032 , TMS320F28032-Q1 , TMS320F28033 , TMS320F28033-Q1 , TMS320F28034 , TMS320F28034-Q1 , TMS320F28035 , TMS320F28035-Q1 , TMS320F28050 , TMS320F28051 , TMS320F28052 , TMS320F28052-Q1 , TMS320F28052F , TMS320F28052F-Q1 , TMS320F28052M , TMS320F28052M-Q1 , TMS320F28053 , TMS320F28054 , TMS320F28054-Q1 , TMS320F28054F , TMS320F28054F-Q1 , TMS320F28054M , TMS320F28054M-Q1 , TMS320F28055 , TMS320F2806-Q1 , TMS320F28062 , TMS320F28062-Q1 , TMS320F28062F , TMS320F28062F-Q1 , TMS320F28063 , TMS320F28064 , TMS320F28065 , TMS320F28066 , TMS320F28066-Q1 , TMS320F28067 , TMS320F28067-Q1 , TMS320F28068F , TMS320F28068M , TMS320F28069 , TMS320F28069-Q1 , TMS320F28069F , TMS320F28069F-Q1 , TMS320F28069M , TMS320F28069M-Q1 , TMS320F28075 , TMS320F28075-Q1 , TMS320F28232 , TMS320F28232-Q1 , TMS320F28234 , TMS320F28234-Q1 , TMS320F28235 , TMS320F28235-Q1 , TMS320F28332 , TMS320F28333 , TMS320F28334 , TMS320F28335 , TMS320F28335-Q1 , TMS320F28374D , TMS320F28374S , TMS320F28375D , TMS320F28375S , TMS320F28375S-Q1 , TMS320F28376D , TMS320F28376S , TMS320F28377D , TMS320F28377D-Q1 , TMS320F28377S , TMS320F28377S-Q1 , TMS320F28379D , TMS320F28379D-Q1 , TMS320F28379S

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1What Is JTAG?
  5. 2Common JTAG Debug Probes
  6. 3Debug Steps for LaunchPad™ Development Kits and controlCARDs
    1. 3.1 LaunchPad™ Development Kits
    2. 3.2 controlCARDs
  7. 4Common Error Codes
    1. 4.1 Common Error Codes
  8. 5Multiple Devices in JTAG Chain
  9. 6JTAG Connectivity Debug Flows
    1. 6.1 Overall Debug Flow
    2. 6.2 High-Voltage Isolation Check Flow
    3. 6.3 Main JTAG Debug Flow
  10. 7Detailed Flow Step Information
    1. 7.1 Isolation Pre-Check Flow
    2. 7.2 JTAG Debug Flow
  11. 8References
  12. 9Revision History

7.2 JTAG Debug Flow

  1. Using Onboard Debug Probe:
    1. Yes: Many C2000 MCU boards have a JTAG debug probe implemented on the PCB. Unless there is an application requirement, TI suggests using the onboard debug probe for development purposes. The XDS100 and the XDS110 are two target debug probes that are found on TI C2000 Evaluation Modules (EVMs).
    2. 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 pullup or pulldown values to provide proper behavior. If the PCB is manufactured by TI, this step can be skipped.
  2. 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 voltmeter. All of TI C2000 development boards have LEDs 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.
  3. 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 5V from the USB to power the EVM. A simple check can be to change the USB cable to make sure this is not the issue. If there is insufficient power from the host, a powered USB hub can help as well.
  4. Switch to an External Power Supply: If the onboard power supply of the TI-built board is not providing power at the appropriate level and the USB cables are known to be good, try switching 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.
  5. 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 7-1) and locate the associated debug probe.
    Microsoft Windows 10 Device Manager Showing Successful Detection of XDS110 Debug Probe Figure 7-1 Microsoft® Windows® 10 Device Manager Showing Successful Detection of XDS110 Debug Probe
  6. Reprogram Emulation Controller: This step makes sure that the device that functions as the emulation controller has the correct firmware.
    1. XDS100v1: The host device is the FTDI FT2232 following guide on re-programming
    2. XDS100v2: The host device is the FTDI FT2232following guide on re-programming
    3. XDS110: The host device is a TI MCU TM4C1294NCPDRI3R following guide for re-programming.
  7. 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.
  8. 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) goes 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 operating system of the host.
  9. 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 7-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 7-3 ) is 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. 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.
    Target Configurations View Figure 7-2 Target Configurations View
    Test Connections Figure 7-3 Test Connections
  10. 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 cores and select "Connect Target". The other way is to use the Debug Button (Figure 7-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 drop-down menu 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, TI recommends using 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.
    Code Composer Debug Button Figure 7-4 Code Composer Debug Button
  11. XRSn State: Looking at XRSn on an oscilloscope, XRSn needs to be inactive high when the device is operational. XRSn low, or pulsing from low to high to low, can indicate one of several issues. If the pulses are periodic, it is likely the watchdog (WD) on the MCU is causing the reset because it is not being serviced or is not disabled. This toggle behavior is not a bad thing, indicating that the MCU is powering up, and executing code, but the behavior can cause instability in the debug flow. If there is non-determinate pulsing or XRSn is always low, this can indicate that the internal Brown Out Reset (BOR) is being triggered due to a supply voltage issue or some issue on the PCB. This is different than the previously-mentioned static supply checks. Both of these potential issues can also happen during code execution. The issues can either disconnect the debug session or prevent it from reliably connecting.
  12. Change BootMode: Check the hardware files to make sure 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 puts 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.
  13. 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, put the device in Wait Boot Mode.
  14. 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, 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 ought to be OK, by design and at this point the checks are being done to verify the board integrity is good.
  15. 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 make sure that the device is supplied with the inputs required to function correctly. Many Piccolo™ class devices have a built in, zero pin oscillator. Using this as the functional clock can be helpful in case of external clock uncertainty. For the available clock sources and the tolerances, see the device-specific data sheet. While the JTAG clock is typically maintained at the default speed from the initial setup file, slowing down the clock rate can be helpful to see if this improves the initial connection or connection stability. This can be especially helpful on custom designed PCBs.
  16. Second Device Check: If after all the previous steps do not fix the issue, a second PCB or EVM can possibly 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.
  17. 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, this mode does not correct the issue of access to secure memory while debugging. 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, the device cannot be unlocked. Debug is limited to unsecured regions.
  18. 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, questions or issues can be posted to the TI C2000 Engineer To Engineer Forum. When posting, please provide the following information in addition to documenting the issue:
    1. Subject or Title of the Post: "JTAG Connectivity Issue - (Insert Part Number here)
    2. CCS Version
    3. Debug Probe Used
    4. Type of target: TI made EVM or custom
    5. Confirmation of which steps in this guide were taken
    6. Custom board schematics of the JTAG connection, if possible, if not a TI EVM