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/LAUNCHXL2-570LC43: Error 1170 @ 0x0 - unable to access the DAP

Part Number: LAUNCHXL2-570LC43
Other Parts Discussed in Thread: UNIFLASH

Tool/software: Code Composer Studio

Hello,

I've recently started to use the Hercules LaunchXL2-570LC43 board. I've managed to place several examples working and everything was fine.

But now the CCS cannot connect to the board. I've look at this forum to try to find a solution but could not.

The full error is:

Error connecting to the target:
(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 7.0.48.0)

I've tried with a slower JTAG (100 KHz and 1MHz), reset my computer, bypass the IcePick and Dap, reset the board, use the uniflash program to connect to the board but nothing is able to perform a "connect". However, the test connection gives OK:

[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/mcoutinho/.ti/ti/1/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 'Jul 21 2017'.
The library build time was '19:29:13'.
The library package version is '7.0.48.0'.
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]

and I know the board is executing the last loaded program (I can see the SCI output on my console when i reset the board).

I guess my problem is connecting to the board (the "Connect to target" option does not work).

I'm using CCS 7.3.0.00019

Thank you in advance

  • Hi,

    The error is described in the reference below.
    software-dl.ti.com/.../ccsv7_debugging_jtag_connectivity_issues.html

    An alternative to try and unlock the device is described in the e2e thread below:
    e2e.ti.com/.../2020352

    Hope this helps,
    Rafael
  • Hello,

    Thanks for the pointers. Unfortunately I was not able to solve the issue. The 11 steps that Charles Tsai pointed out helped a bit (I think):

    1) In CCS, View->Target Configurations

    2) In the target configurations tab that pops up, find the correct .ccxml for your target board.

    3) Right click on the CCXML and "Launch Selected Configuration".

    4) The "Debug" tab should open. You will see your CCXML file at the top of the tree. The next node down is the CPU/Emulator line with the Cortex R as a target.

    5) Right Click on the cortex R target line (with the X).

    6) From the context menu select "Show all Cores"

    7) You should see now that there are connections available to IcePickC and DAP under 'Non Debuggable Devices"

    8) Right click on IcePickC only and do a 'connect to target'.

    9) If you are able to connect to IcePick then issue a system reset (Debug->System Reset)

    10) Now try to connect to the DAP just like you did with IcePick C. Can you connect now?

    11) If the last step is successful then connect to the Cortex R. You may have to 'retry' a bunch of times like 10's or more times while pressing the 'reset' (not Power on Reset) button.

    I was able to do up to step 10. I was able to setup the IcePick and DAP connections. With DAP I could see the memory on the memory browser. However the last step (11) I could not make it to connect. At most the state was "Suspended" and when i try to load an image an error occurred (or after a while the state when to "Disconnected: Running" again).

    I tried step 10 by pushing the board RESET button 100s of times. I also tried the "POWER ON RESET" (PORRST) button but then the Icepick and Dap disconnected (makes sense from that link you sent, the power on reset would reset the debug as well).

    This is the log:

    CortexR5: 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 7.0.48.0)
    CortexR5: Unable to determine target status after 20 attempts
    CortexR5: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

    Given this message I tried to reset the emulator, i even reset the host and the board but this "there may still be breakpoints" message still appears.

    Is it possible to erase the flash with just IcePick or DAP connected? I tried to find an option but could not find it.

    Or any other suggestion?

    Thanks!

  • Manuel,

    Thanks for sending the details. Step 11 is absolutely critical and narrows the origin of the problem to the core itself - given you are able to connect to it for some time suggests an active watchdog is resetting the core and therefore causing the disconnection. Given you have access to the DAP, which in turn has access to all memory seen by the core, you can try to find the address to the watchdog timer registers and disable it.

    I don't know how to wipe the Flash memory from the DAP - perhaps the experts at the Hercules forum would know better. I notified someone on that group to take a look at this.

    In the meantime, I will keep trying to see if there are alternatives to erase the Flash memory.

    Regards,
    Rafael
  • Hi Manuel,
    You can only erase the flash after the core is connected. You might want to short the OSCIN and OSCOUT in the board and this will intentionally create an OSC fail and the MCU will fallback to its internal limp clock. The limp clock run slower and may allow you a higher chance to connect to the core. What you want is to be able to connect to the core before the core executes the offending instruction that causes the debugger unable to connect.
  • Thank you Rafael and Charles,

    I follow the steps again, but this time pushing the "KILL OSC" button (to do as you suggested, to short the OSCIN and OSCOUT) and I can connect to the board again, after a few tries (on step 11).

    I am now able to erase the flash and to load a program again.

    Thank you again for the support!

    Manuel