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 v11.1 - Debug mode, error -1170 and -2064

Other Parts Discussed in Thread: CC1352R, CC3120MOD

Hello,

We have a product developed before 1 year with CC1352R and CC3120MOD. The project is created with WIFI plugin simplelink_sdk_wifi_plugin_2_40_00_22 and simplelink_cc13x2_26x2_sdk_4_10_00_78.

Now the project is transferred to new PC with Win 10 Pro. There is an absolutely new installation of CCS 11.1. The project can be compiled, but cannot be debugged. Always the error is: 

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.6.0.00172)
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.6.0.00172)
Cortex_M4_0: Unable to determine target status after 20 attempts
Cortex_M4_0: 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

We tried almost everything  recommended by TI. We have:

1. Successful test communication with XDS110.

2. The current TCLK is only 1.5MHz. It is tested even with the smallest frequency 100kHz. Always the communication test is successful.

3. When we press the button "Debug" the program is loaded successfully and wait in the beginning of the main(). When we resume the execution it starts and typically stops with error somewhere around the execution of the code for the Sensor Controlled. ALWAYS the error is -1170 and later -2064.

4. If we mass erase the chip with Flash Programmer 2, the first debug session is successful, bet after Restart of the execution everything starts AGAIN with error -1170.

After 1 month attempts we really don't have any ideas how to continue. Could help us?

  • Hello,

    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.6.0.00172)
    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.6.0.00172)

    These errors are usually do to some communication issue between the debug probe (XDS110) and the device. The errors are usually due to some low level hardware connection issues or because the device went into a bad state:

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

    https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html#device-status

    3. When we press the button "Debug" the program is loaded successfully and wait in the beginning of the main(). When we resume the execution it starts and typically stops with error somewhere around the execution of the code for the Sensor Controlled. ALWAYS the error is -1170 and later -2064.

    4. If we mass erase the chip with Flash Programmer 2, the first debug session is successful, bet after Restart of the execution everything starts AGAIN with error -1170.

    It sounds like the program somehow could be putting the device in a bad state. 

    After a mass-erase. if you do a manual (project-less) launch and then manually connect to the target. Is that fine? Can you press the "resume" button without the errors occuring?

    Thanks

    ki

  • Hello,

    Thanks for the information but the problem exists again.

    1. We have successful test communications with TCLK 0.5MHz, 1.5MHz and 5.5MHz.

    2. We can program and erase the device using Flash Programmer 2.

    3. We can program the device using CCS and Image Creator.

    But we cannot debug the device.

    Today We did very simple test using the available example - nortos/watchdog. The result is absolutely the same. We cannot enter in Debug mode but the code works properly if it is programmed.

    We discovered one very important thing. The Debug session is successful ONLY after MASS ERASE using the Flash Programmer 2. ALWAYS the first attempt to debug is successful. After that if we restart the Debug session always the error is -1170 and -2064.

    We enabled the Verbose output of the Flashloader and the result is very interesting.

    1. If the chip is Mass Erased, the first Debug session is successful and the first loading of the output file always will finished. See the log.

    Cortex_M4_0: GEL Output: Memory Map Initialization Complete.
    Cortex_M4_0: Flashloader: Verbose output enabled.
    Cortex_M4_0: GEL Output: Memory Map Initialization Complete.
    Cortex_M4_0: GEL Output: Board Reset Complete.
    Cortex_M4_0: Writing Flash @ Address 0x00000000 of Length 0x00003438
    Cortex_M4_0: Loading flashloader to target: FlashLoaderCC26x2.out
    Cortex_M4_0: Chunk 1: addr=0x00000000, length=8192, crc=0xA27ED071 (using block 0)
    Cortex_M4_0: Chunk 2: addr=0x00002000, length=5176, crc=0xF98B40A6 (using block 1)
    Cortex_M4_0: Writing Flash @ Address 0x00003438 of Length 0x00000004
    Cortex_M4_0: Chunk 1: addr=0x00003438, length=4, crc=0x2144DF1C (using block 0)
    Cortex_M4_0: Writing Flash @ Address 0x00003440 of Length 0x00000080
    Cortex_M4_0: Chunk 1: addr=0x00003440, length=128, crc=0x4ADCE05D (using block 1)
    Cortex_M4_0: Writing Flash @ Address 0x00057fa8 of Length 0x00000058
    Cortex_M4_0: Chunk 1: addr=0x00057FA8, length=88, crc=0x3FA2C9EF (using block 0)

    2. If we repeat the Debug session always it is not successful. See the log.

    Cortex_M4_0: GEL Output: Memory Map Initialization Complete.
    Cortex_M4_0: Flashloader: Verbose output enabled.
    Cortex_M4_0: GEL Output: Memory Map Initialization Complete.
    Cortex_M4_0: GEL Output: Board Reset Complete.
    Cortex_M4_0: Writing Flash @ Address 0x00000000 of Length 0x00003438
    Cortex_M4_0: Loading flashloader to target: FlashLoaderCC26x2.out
    Cortex_M4_0: Chunk 1: addr=0x00000000, length=8192, crc=0xA27ED071 (using block 0)
    Cortex_M4_0: Chunk 2: addr=0x00002000, length=5176, crc=0xF98B40A6 (using block 1)
    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.6.0.00172)
    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.6.0.00172)
    Cortex_M4_0: JTAG Communication 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.6.0.00172)
    Cortex_M4_0: Command=19 -- addr=0x00002000 -- length=0x00001438
    Cortex_M4_0: File Loader: Memory write failed: Could not read 0x20000B4C: target is not connected
    Cortex_M4_0: GEL: File: C:\Users\Admin\workspace_v11\watchdog_CC1352R1_LAUNCHXL_nortos_ccs\Debug\watchdog_CC1352R1_LAUNCHXL_nortos_ccs.out: Load failed.

    3. New Mass Erase fixes the problem.

    Now please tell me why the device is locked and cannot be reprogrammed? All settings in CCS are the default settings. There are not any enabled protection features. Why after Mass Erase the default state of the chip is not restored and preserved?

    Thanks in advance for your responses.

  • Can you enable debug server logging and reproduce the issue?

    https://software-dl.ti.com/ccs/esd/documents/ccs_diagnostic-logs.html#debug-server-logs

    Then zip the log and attach it to this thread.

    Would it be also possible to share the CC1352 *.out file being loaded (you can share via private E2E message)?

    Thanks

    ki

  • Hello,

    Please the attached files. Nothing hidden The output file is from the example nortos/watchdog.

    I hope that the log files contains all situation when the device is MASS ERASE and there is a successful Debug session and after that a second not successful Debug session.3240.ds.logwatchdog_CC1352R1_LAUNCHXL_nortos_ccs.zip

    The output file is zip file because the size is to big to be loaded here. Unzip the file.

  • Thank you for the files. I am unable to reproduce the issue on my CC1352 LaunchPad. I have send the log to engineering for review. I will keep you post of anyy updates as I receive them.

    Thanks

    ki

  • Engineering has analyzed the logs and can see that the device disconnects and does a board reset before flashing. The -1170 error occurs during the initial disconnect. While the reset does occur, the error keeps happening afterwards.

    As for why the error occurs, we are still unsure. Going back to:

    3. When we press the button "Debug" the program is loaded successfully and wait in the beginning of the main(). When we resume the execution it starts and typically stops with error somewhere around the execution of the code for the Sensor Controlled. ALWAYS the error is -1170 and later -2064.

    4. If we mass erase the chip with Flash Programmer 2, the first debug session is successful, bet after Restart of the execution everything starts AGAIN with error -1170.

    Just to clarify, does #3  occur right after the mass erase? Meaning successful programming of the device and the debugger successfully started and application at main? Then when you run, the error occurs. Shutting down and trying again keeps getting the error. Is this correct?

    Meaning that you always get the errors, it is just that just after a mass erase, the error only happens once the application gets stuck in the code for the sensor controller?

  • Also, are you using a custom board?

  • Yes, this is a custom board. It works properly in Release mode. We can erase and program the board using the Flash Programmer 2. Even it is certified.

  • Yes, correct. You can see the first logs when the verbose mode is enabled. I discovered that if the device is erased (not MASS erase, standard erase operation) with Flash Programmer 2, always the first Debug session can be loaded successfully. Any other operations after that are not successful to the next erase operation. That is why, my question here is why the FlashLoader in the CCS can't erase the device, but the app Flash Programmer 2 can?

  • I will need to bring this thread to the attention of the device experts. I suspect that the the device is being put in a bad state somehow which is causing the errors.

  • From the description it sounds like the problem started when you moved to a new workspace. I note that you use CCS 11.1 but the SDK you are using have been tested with CCS 10.0. We have seen before that using a newer CCS version than stated in the release notes may give strange errors. Could you test also with CCS 10.0 to rule out the CCS version? As I understand the problem description this issue popped up when you moved to a different PC. Did you do more changes than switching to CCS 11.1? As I understand it the custom board is known good and as I read it you have successfully debugged this before? 

  • Hello TER,

    You understand very well the situation. The project is developed with CCS v9.2. Now everything is moved on new PC with Win 10 Pro and the last version of CCS v11.1. The compiler is the same, the SDKs are the same. The Image Creator and the Flash Programmer 2 are the last version.

    Today I will test the project using CCS 10.0. I don't believe that there will be a difference. We will see.