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/PROCESSOR-SDK-DRA8X-TDA4X: Connection Problems when using CCS10 and the XDS560v2 emulator: (Error -1170 @ 0x0) Unable to access the DAP

Part Number: PROCESSOR-SDK-DRA8X-TDA4X


Tool/software: Code Composer Studio

Hi,

I am facing a problem when trying to connect to the target TDA4VM when using CCS10 and the XDS560v2 emulator (Blackhawk). When setting up the target configuration file and testing the connection everything seems to work fine. But when trying to connect to the target core for debugging purposes, I got the following Error Message:

MAIN_Cortex_R5_0_1: 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 9.1.0.00001) 

I tried the suggested change of settings (eg. power-cycle the board, lower TCLK to 5.0MHz, ...) but couldn't find a configuration which worked.

Do you have an idea where the problem is ?
Thanks for your help !

Zoe

I got this output from the testing routine within the CCS:

[Start]

Execute the command:
%ccs_base%/common/uscif/dbgjtag.exe -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

[Result]

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

C:\Users\zoesu\AppData\Local\Texas Instruments\
CCS\ccs1000\0\0\BrdDat\testBoard.dat

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

This utility has selected a 560/2xx-class product.
This utility will load the program 'bh560v2u.out'.
Loaded FPGA Image: C:\ti\ccs1000\ccs\ccs_base\common\uscif\dtc_top.jbc
The library build date was 'Feb 13 2020'.
The library build time was '17:21:13'.
The library package version is '9.1.0.00001'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '6' (0x00000006).
The controller has an insertion length of '0' (0x00000000).
The cable+pod has a version number of '8' (0x00000008).
The cable+pod has a capability number of '7423' (0x00001cff).
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 Nano-TBC VHDL.
The link is a 560-class second-generation-560 cable.
The software is configured for Nano-TBC VHDL features.
The controller will be software reset via its registers.
The controller has a logic ONE on its EMU[0] input pin.
The controller has a logic ONE on its EMU[1] input pin.
The controller will use falling-edge timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '2' (0x0002).
The utility logic has not previously detected a power-loss.
The utility logic is not currently detecting a power-loss.
Loaded FPGA Image: C:\ti\ccs1000\ccs\ccs_base\common\uscif\dtc_top.jbc

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

Test Size Coord MHz Flag Result Description
~~~~ ~~~~ ~~~~~~~ ~~~~~~~~ ~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
1 none - 01 00 500.0kHz - similar isit internal clock
2 none - 01 09 570.3kHz - similar isit internal clock
3 64 - 01 00 500.0kHz O good value measure path length
4 16 - 01 00 500.0kHz O good value auto step initial
5 16 - 01 0D 601.6kHz O good value auto step delta
6 16 - 01 1C 718.8kHz O good value auto step delta
7 16 - 01 2E 859.4kHz O good value auto step delta
8 16 + 00 02 1.031MHz O good value auto step delta
9 16 + 00 0F 1.234MHz O good value auto step delta
10 16 + 00 1F 1.484MHz O good value auto step delta
11 16 + 00 32 1.781MHz O good value auto step delta
12 16 + 01 04 2.125MHz O good value auto step delta
13 16 + 01 11 2.531MHz O good value auto step delta
14 16 + 01 21 3.031MHz O good value auto step delta
15 16 + 01 34 3.625MHz O good value auto step delta
16 16 + 02 05 4.313MHz O good value auto step delta
17 16 + 02 13 5.188MHz O good value auto step delta
18 16 + 02 1B 5.688MHz {O} good value auto step delta
19 64 + 01 3B 3.844MHz O good value auto power initial
20 64 + 02 0B 4.688MHz O good value auto power delta
21 64 + 02 13 5.188MHz O good value auto power delta
22 64 + 02 17 5.438MHz O good value auto power delta
23 64 + 02 19 5.563MHz O good value auto power delta
24 64 + 02 1A 5.625MHz O good value auto power delta
25 64 + 02 1A 5.625MHz O good value auto power delta
26 64 + 02 10 5.000MHz {O} good value auto margin initial

The first internal/external clock test resuts are:
The expect frequency was 500000Hz.
The actual frequency was 499110Hz.
The delta frequency was 890Hz.

The second internal/external clock test resuts are:
The expect frequency was 570312Hz.
The actual frequency was 569976Hz.
The delta frequency was 336Hz.

In the scan-path tests:
The test length was 2048 bits.
The JTAG IR length was 4 bits.
The JTAG DR length was 1 bits.

The IR/DR scan-path tests used 26 frequencies.
The IR/DR scan-path tests used 500.0kHz as the initial frequency.
The IR/DR scan-path tests used 5.688MHz as the highest frequency.
The IR/DR scan-path tests used 5.000MHz as the final frequency.

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

The frequency of the JTAG TCLKR input is measured as 4.994MHz.

The frequency of the JTAG TCLKR input and TCLKO output signals are similar.
The target system likely uses the TCLKO output from the emulator PLL.

-----[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 4 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]

 

  • Hi, Zoe:

    I am sure what problem it is.

    But I want to double check with you, whether you have noticed the guide here:

    https://software-dl.ti.com/ccs/esd/documents/ccsv10_linux_host_support.html

  • Hello Zoe,

    zoe0423 said:
    MAIN_Cortex_R5_0_1: 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 9.1.0.00001) 

    For more details on this error (and for some troubleshooting tips), please see the below link:

    https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html#cannot-access-the-dap

    It looks like you tried a low level JTAG connectivity test and the results look good (pass). Hence it does not appear to be a HW connection issue. Hence it is more likely to be an issue with target initialization. Were you able to connect to this board in the past?

    Thanks

    ki

  • Hi Ki,

    Were you able to connect to this board in the past?

    > I connected this board and debug application thru loading DMSC firmware in the past, and this is my first try to debug application thru SD card firmware.

  • Hi, :

    Since the system up is up and running with firmware from SD card, the "launch.js" from PDK folder cannot be used anymore.

    Please launch the target configuration directly, and connect to the core you are working with.

    (make sure the startup script is removed for that particular core)

  • Hi Peter,

    Thanks for your response, but I only using "launch.js" while loading DMSC firmware (without SD card Boot). 

    While system is running with firmware from SD card, I actually only launch the target configuration directly, and connect to the MAIN_Cortex_R5_0_1.

    Then got this error.

    MAIN_Cortex_R5_0_1: 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 9.1.0.00001) 

    Reconfirm my target configuration only setup start script for DMSC core.

  • Hi, :

    I have a doubt: is MAIN_Cortex_R5_0_1 up and running?

    Can you please try other cores? such as MCU_Cortex_R5_0_0 (this is the boot master core)?

  • Hi Zoe,

    As  mentioned you will be able to connect to the core only when that code is powered on.

    By power on I mean - you have a firmware in the SD card which gets loaded on to that particular code and then takes that core out of reset.

    You can look at the boot logs from the u-boot and see a print like below:

    Load Remote Processor 6 with data@addr=0x80080000 1513520 bytes: Success!
    1513520 bytes read in 36 ms (40.1 MiB/s)

    This means that remote core 6 i.e C66_0 core. I am pretty sure you won't see a print saying Load Remote Processor 3 (corresponding to MAIN_Cortex_R5_0_1).

    There is an FAQ at https://e2e.ti.com/support/processors/f/791/t/915474 which explains all this loading of firmwares from u-boot / SPL etc.. 

    So now coming back to how it worked before?

    Initially you were using the no-boot i.e. using the launch.js and that actually runs the GEL file instead of the ROM + Bootloader code. The GEL files take ALL the cores out of reset and that is why you can connect to any core.

    Hope this clarifies things.

    Regards,

    Karan

  • Hi Karan, 

    Thanks for your explanation. It's very clear now.