• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 2696 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/CCSTUDIO: (Error -1170 @ 0x0) Unable to access the DAP - works after reboot

Simon Falsig
Intellectual 350 points
Part Number: CCSTUDIO
Other Parts Discussed in Thread: CC2650

Tool/software: Code Composer Studio

I'm currently having problems debugging a TI CC2650 on a custom PCB. The first few times everything works fine, but then I start getting the following error:

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 6.0.504.4)

I've tried restarting CCS, and re-plugging both PCB and debugger, but none of those solutions usually work. Only way to get around the error seems to be a full reboot, which usually fixes it. I don't really see it is a usable workaround to have to restart my machine whenever I want to reprogram the device though.

My system:

Windows 10

CCS Version: 6.2.0.00050

Spectrum Digital XDS200 debugger

TI CC2650

Any ideas on what could be causing this? - or any suggestions for other workarounds I could try?

Thanks in advance!

  • 0
    TI__Guru**** 171104 points

    Hi,

    The error you are seeing is referenced in section 5.20 of the wiki page below:

    http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems#Cannot_access_the_DAP 

    Per your description it seems the ability to debug becomes inoperative after a few code load and/or flash operations - a few others have been reporting similar scenarios, but unfortunately we couldn't reproduce this here.

    Due to the nature of the problem, it is not uncommon to suspect the loaded firmware as this is usually what can cause the Cortex M core to be inaccessible (spinning in a reset loop, locked in a hard fault, etc.). Therefore I ask: is this typically happening with the same or different code loaded to the target? Can you pinpoint one (or maybe a few) code examples that may trigger this? Some other folks have been reporting this with project zero. 

    Give the suggestions above to try to unlock your device and I will keep trying to reproduce this here. 

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Intellectual 350 points

    Hi Rafael,

    Thanks for the answer!

    I tried looking at the linked page, and I can connect to the DAP core, even when the error shows up. I can't do anything to it though - all options (including reset and similar) are greyed out. I tried the MassErase script, which just made everything worse, to the point where I now can't connect to the chip at all - even after a restart of my computer. It now fails with:

    Error connecting to the target:
    (Error -241 @ 0x0)
    A router subpath could not be accessed.
    A security error has probably occurred.
    Make sure your device is unlocked.
    (Emulation package 6.0.504.4)


    I've gone back to a different board now, but to be honest though, I think my initial problem sounds more like a problem with either CCS or the driver for the debugger (or similar). I can be unable to connect to the system due to the mentioned error, then I shut down my computer (board with CC2650 is powered externally, and runs without being reset during the complete procedure), start it again, and then debugging works consistently on the first try.

    I can also say that I can launch the target configuration, connect to the device, and debug it (stepping, breakpoints and so on) - but when I try to load a program, I get the DAP error.


    If it had been the loaded firmware, then I'd say that the problem should rather depend on restarting the CC2650 board and timing the debugger connection (which I've tried to some extent at least), than on rebooting my computer?

    Any ideas about software that is running in the background on my computer that I can try to manually reset, instead of rebooting the whole machine?

    Thanks in advance!

  • 0 in reply to Simon Falsig
    Intellectual 350 points
    Hi Rafael,

    I did some more experimenting, and it turns out that I can actually program the board after getting the error, by following this procedure:

    - Instead of just going for 'Debug', build the project, then launch the target configuration
    - Connect to the target
    - Do a 'CPU Reset', and wait for the CPU to restart and pause during boot
    - While paused, do a 'Load Program'

    This suggests that it indeed could have something to do with the firmware, although I still find it a bit strange that restarting my computer has the same effect?

    But ah well - I have a workaround now, that's quite a bit less cumbersome than restarting my computer ;)

    Thanks!
  • 0 in reply to Simon Falsig
    TI__Guru**** 171104 points
    Hi,

    Thanks for reporting your findings, but let me ask you: were you ever able to recover the mass erased board?

    I am trying to reproduce this issue here with my CC2650 launchpad but I have not yet found a way to "break it". I will keep trying a few different approaches and report back anything new.

    Regards,
    Rafael
  • 0 in reply to desouza
    Intellectual 350 points
    Hi Rafael,

    I must admit that I simply haven't had time to work more on recovering the mass erased board, so I don't know whether I can get it back to working.

    Regarding being able to reproduce the problem, I can say that I was debugging a modified version of the SPP_BLE_SERVER example project, with one of the tasks overflowing its stack, causing the CC2650 to be stuck in a hard-fault loop after a bus error (PRECISERR) - if that helps?