• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 54 subscribers
  • Views 590 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/LAUNCHXL-CC1352P: Debugging Coprocessor, Unable to access the Dap.

Derek Cole
Prodigy 230 points
Part Number: LAUNCHXL-CC1352P
Other Parts Discussed in Thread: UNIFLASH

Tool/software: Code Composer Studio

As the title says, I am trying to debug coprocessor_CC1352P1_LAUNCHXL_tirtos_ccs from the SDK. I created a debug configuration, and set the ARM Compiler optimizations to off. I am able to succesfully "Debug as.." a code composer studio, and the file is flashed to the board and breaks in main().

It will continue to run fine, however, if I set a breakpoint myself in code composer studio, as soon as the breakpoint is hit I get this in the console:

Cortex_M4_0: GEL Output: Memory Map Initialization Complete.
Cortex_M4_0: GEL Output: Board Reset Complete.
Cortex_M4_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.1.00042)
Cortex_M4_0: Trouble Halting Target CPU: (Error -2062 @ 0x0) Unable to halt device. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.1.00042)
Cortex_M4_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.1.00042)
Cortex_M4_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.1.00042)
Cortex_M4_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.1.00042)
Cortex_M4_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.1.00042)
Cortex_M4_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.1.00042)
Cortex_M4_0: Trouble Halting Target CPU: (Error -2062 @ 0x0) Unable to halt device. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.1.00042)
Cortex_M4_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.1.00042)

................repeating

I have tried everything I can think of. I have updated the firmware to 3.0.0.14, I have tried to change the JTAG TCLK Frequency to Higher and lower values (10mhz and 2.5mhz), I have tried to get this to work on two different LAUNCHXL CC1352P1 boards that I have. I have tried to use the Scripts->Mass Erase from code composer studio, as well as the Erase function in Uniflash, and nothing is working.

What can I do to resolve this error? Is it something to do with the project configuration? I am able to succesfully put breakpoints in, for example, the uartecho project.

Thank you,

Derek

  • 0
    Prodigy 230 points

    I forgot to add, here is the output from my test connection with TCLK set to 5.5MHz

    [Start: Texas Instruments XDS110 USB Debug Probe]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

    [Result]


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

    /home/derek/.ti/ccs1000/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 'libjioxds110.so'.
    The library build date was 'Nov  8 2020'.
    The library build time was '19:20:30'.
    The library package version is '9.2.1.00042'.
    The library component version is '35.35.0.0'.
    The controller does not use a programmable FPGA.
    The controller has a version number of '5' (0x00000005).
    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 XDS110 with USB interface.
    The link from controller to target is direct (without cable).
    The software is configured for XDS110 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).

    -----[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 XDS110 USB Debug Probe]

  • 0
    TI__Guru* 82431 points

    Hi Derek,

    Is your coprocessor connected to a host when this happens?

    Can you try the following:

    1) Make sure no host is connected to the coprocessor

    2) Start a debug session of the coprocessor

    3) Right click on the Cortex_M_M in the Debug view and select Disconnect from target.

    4) Connect the host

    5) In CCS, right-click on the disconnected target and select "Connect Target"

    6) Press play

    7) Send the initialization command from the host.

  • 0 in reply to Marie H
    Prodigy 230 points

    Hello Marie,

    Thanks for the insight. I think I have determined that what I am seeing is expected behavior, because the command being sent to the cc1352 is performing HAL_SYSTEM_RESET which is causing the target to disconnect. When the reset occurs, it seems like i am running into a HaltInBoot situation, where the image is not getting loaded and running again until I reconnect to the target. If I right click the target and click "Connect target" and then Press play, the application continues.

    Is there any way to disable this functionality? The host_collector application is waiting on a response from the board, and that does not happen unless I disconnect/reset the board. 

  • 0 in reply to Derek Cole
    TI__Guru* 82431 points

    Hi Derek,

    My intention with the instructions above is that the reset command is sent in step 4. You can then attach the debug session after this command has been sent.

  • 0 in reply to Marie H
    Prodigy 230 points

    Thank you,

    I think we both realized what the problem is. I guess my question is, why do I need to do it that way? For example, the host_collector example program sends the reset request, and then it never gets a response from the Launchpad after it resets because it is waiting on a JTAG connection to move out of HIB state.

    This documentation mentions this problem and says it has been fixed in later versions of the XDS110 emulator.

    "However, a permanent fix is available. As of version 8.0.27.9 of the emulation software package, the XDS110 emulator now drives the TCK pin high instead of leaving it in tri-state. This removes any unwanted toggling on the TCK pin after a system reset, which no longer triggers HIB."

    It looks like according to my previous post, I am using version '9.2.1.00042'. Does this indicate that the bug has resurfaced?