This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28021: "Device Held in Reset" error when trying to Connect To Target

Part Number: TMS320F28021

Hello~

I'm bringing up a new PCB of our own design, which is based on a mature product using a similar TI Piccolo chip.

The new PCB uses the TMS320F28021 chip, and we are using the Blackhawk USB100v2 (BH-USB-100v2) emulator probe for the JTAG connection.
We have the same result with v7 aand v9 of CCS.
The chip is running a 20Mhz Crystal, 8pf caps, and the clock waveform is a solid 20Mhz wave.
Power to the chip (Vdd and VDDIO) is 3.3V, solid and clean.
The JTAG Probe, and the interconnecting wire, are all known and tested good with another product.

Originally, I had the chip bootstrapped to "FLASH BOOT", but changed it to "WAIT BOOT" in the process of troubleshooting this problem.

The project is a simple while(1) that increments a counter, just for testing.
Following is a dump of the Console messages:

C28xx: Failed CPU Reset: (Error -1137 @ 0x6) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 6.0.504.0)
C28xx: Trouble Reading Register PC: (Error -1137 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 6.0.504.0)
C28xx: Trouble Reading Register ST1: (Error -1137 @ 0x6) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 6.0.504.0)
C28xx: GEL: Error while executing OnReset(1): Target failed to read register ST1
at (ST1&~(0x0100)) [f28021.gel:282]
at C28x_Mode() [f28021.gel:32]
at OnReset(1)
C28xx: Flash Programmer: Warning: The configured device (TMS320F28021), does not match the detected device (). Flash Programming operations could be affected. Please consider modifying your target configuration file.
C28xx: Failed CPU Reset: (Error -1137 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 6.0.504.0)
C28xx: Trouble Reading Register PC: (Error -1137 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 6.0.504.0)
C28xx: Trouble Reading Register ST1: (Error -1137 @ 0x6) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 6.0.504.0)
C28xx: GEL: Error while executing OnReset(1): Target failed to read register ST1
at (ST1&~(0x0100)) [f28021.gel:282]
at C28x_Mode() [f28021.gel:32]
at OnReset(1)
C28xx: Trouble Writing Memory Block at 0x8000 on Page 0 of Length 0xe8: (Error -1137 @ 0x8002) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 6.0.504.0)
C28xx: File Loader: Verification failed: Target failed to write 0x08000@Program
C28xx: GEL: File: /home/shared/workspace_v7/Test_TMS320F28021_PG2/Debug/Test_TMS320F28021_PG2.out: Load failed.

return 0;

  • Hello, 

    This has been assigned to an expert.  In the meantime you may find the C2000 JTAG Troubleshooting Guide helpful.

    https://www.ti.com/lit/spracf0

    Regards

    Lori

  • Thanks! 
    I already went through that guide and tried the things it suggested.

    Cheers,

    ~Rod

  • Just to note - we are still facing this problem, despite having gone through the Troubleshooting guide and checking our design and implementation thoroughly.

    Thanks

  • Rod,

    I'd like to try and connect to the device w/o using the "launch debug" button, or from a target project, the reason is that method combines several steps/actions and if one fails we don't really have a good indication what is causing the issue:

    1)Let's double check the target config file(if already done you can skip this), has the correct device(F28021) and emulator selected(Blackhawk).

    2)Once this is saved, you should see a button in that same setup window to "test connection"  let's run  this and see what the results are.

    3)I'm going to assume this passes, esp since you have the device in Wait Boot mode, if it fails we can debug differently, let me know.

    4)At this point we have verified the connection is good.  Let's launch the connection fully by right clicking on the .ccxml and picking "launch target config"

    5)This should bring up the target and CPU listing, you'll then want to click on the CPU and pick "connect"

    6)Once we are here, we can try to load your project(manually) by going to the Run->Load Program.

    Let's see where we get in the above. and we can go from there.

    Best,

    Matthew

  • Hello again:

    Finally getting back to this project.  To address the points you presented:

    1. The Target Config is as close as possible.  We are using a Blackhawk USB100v2 emulator (ser#ND7414).  We have the "Texas Instruments XDS100v2 USB Debug Probe" selected as there is no direct "Blackhawk" match in the available emulator/debug probe selection.  This selection passes the "Verify" test from the Project Properties/Debug settings screen.  The "Blackhawk USB560..." selections all fail the basic verification.

    2.  The "Test Connection" completes and states that it succeeded.  The Output from the test is:

    [Start: Texas Instruments XDS100v2 USB Debug Probe]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

    [Result]


    -----[Print the board config pathname(s)]------------------------------------

    /home/shared/.ti/ccs1010/0/0/BrdDat/testBoard.dat

    -----[Print the reset-command software log-file]-----------------------------

    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'libjioserdesusb.so'.
    The library build date was 'May 7 2020'.
    The library build time was '20:44:54'.
    The library package version is '9.2.0.00002'.
    The library component version is '35.35.0.0'.
    The controller does not use a programmable FPGA.
    The controller has a version number of '4' (0x00000004).
    The controller has an insertion length of '0' (0x00000000).
    This utility will attempt to reset the controller.
    This utility has successfully reset the controller.

    -----[Print the reset-command hardware log-file]-----------------------------

    The scan-path will be reset by toggling the JTAG TRST signal.
    The controller is the FTDI FT2232 with USB interface.
    The link from controller to target is direct (without cable).
    The software is configured for FTDI FT2232 features.
    The controller cannot monitor the value on the EMU[0] pin.
    The controller cannot monitor the value on the EMU[1] pin.
    The controller cannot control the timing on output pins.
    The controller cannot control the timing on input pins.
    The scan-path link-delay has been set to exactly '0' (0x0000).

    -----[The log-file for the JTAG TCLK output generated from the PLL]----------

    There is no hardware for programming the JTAG TCLK frequency.

    -----[Measure the source and frequency of the final JTAG TCLKR input]--------

    There is no hardware for measuring the JTAG TCLK frequency.

    -----[Perform the standard path-length test on the JTAG IR and DR]-----------

    This path-length test uses blocks of 64 32-bit words.

    The test for the JTAG IR instruction path-length succeeded.
    The JTAG IR instruction path-length is 38 bits.

    The test for the JTAG DR bypass path-length succeeded.
    The JTAG DR bypass path-length is 1 bits.

    -----[Perform the Integrity scan-test on the JTAG IR]------------------------

    This test will use blocks of 64 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.

    The JTAG IR Integrity scan-test has succeeded.

    -----[Perform the Integrity scan-test on the JTAG DR]------------------------

    This test will use blocks of 64 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.

    The JTAG DR Integrity scan-test has succeeded.

    [End: Texas Instruments XDS100v2 USB Debug Probe]

    3.  This seems to represent a successful connection/JTAG test.

    4.  From the Target Configuratios window, I right-click the ccxml file in the hierarchical tree: Projects/TestPCB094/targetConfigs/TMS320F28021.ccxml, and select "Launch Selected Configuration".

    This brings up a short tree in the "Debug" window:

    TMS320F28021.ccxml [Code Composer Studio - Device Debugging

    \ Texas Instruments XDS100v2 USB Debug Probe/C28xx (Disconnected:Unknown)

    5.  I right-click on the last line of this listing "Texas Instruments XDS100v2 USB Debug Probe/C28xx (Disconnected:Unknown)" and select "Connect Target".

    The result is the "Device held in Reset" error, the complete text of which is:

    C28xx: Failed CPU Reset: (Error -1137 @ 0x6) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 9.2.0.00002)
    C28xx: Trouble Reading Register PC: (Error -1137 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 9.2.0.00002)
    C28xx: Trouble Reading Register ST1: (Error -1137 @ 0x6) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 9.2.0.00002)
    C28xx: GEL: Error while executing OnReset(-1): Target failed to read register ST1
    at (ST1&~(0x0100)) [f28021.gel:282]
    at C28x_Mode() [f28021.gel:32]
    at OnReset(-(1))
    C28xx: GEL: Error while executing OnTargetConnect(): Reset failed: retcode=-1
    at GEL_Reset() [f28021.gel:93]
    at OnTargetConnect()

    From this point, Step 6 is not really do-able...

    I can tell you that if I just click the "Debug" (Bug icon) from the CCS toolbar, I get a similar printout in the Console window, with the addition of

    C28xx: Flash Programmer: Warning: The configured device (TMS320F28021), does not match the detected device (). Flash Programming operations could be affected. Please consider modifying your target configuration file.

    It appears that the Debugger cannot even read any kind of device ID from the target.

    This is on Ubuntu 16.04 Xenial, and a fresh install of  Code Composer Studio, Version: 10.1.0.00010.

    Thanks very much for any information you can provide about this!  

    ~Rod

  • Rod,

    Thanks for looking at this and providing the detail.  As you said the fact that the JTAG Test dialogue shows all passing is a positive that we can talk/control the MCU with the debugger/CCS IDE.  

    Since CCS is reporting that the device is held in reset when we try to connect; I would like to put a scope on the XRSn pin and observe the pin state; if the pin is low that is indeed the issue and we can debug why it is being held active low. 

    If it is high, then there is some issue in the debug logic of the device that is blocking the emulation connection.  Since you have the device in Wait Boot, I don't think we should see a toggle on XRSn, which would be the internal WD timing out over and over again; even so that shouldn't block access.

    The Wait Boot should prevent the most common reason for not allowing a debug connection, which is the device security is active.  This shouldn't be an issue with a fresh factory devices anyway though.

    Will look for the status of the XRSn pin and go from there.

    Best,
    Matthew