• State
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 52 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS320C6678: Trouble Halting Target CPU: (Error -1060 @ 0x0) Device is not responding to the request.

rick szajdecki
Prodigy 70 points
Part Number: TMS320C6678

Tool/software:

after some unknown event happens where a C6678 DSP core hasn’t responded to a watchdog timer,  when the user attempts to halt the DSP core via the IDE , the following error is displayed in the console window:

“C66xx_2: Trouble Halting Target CPU: (Error -1060 @ 0x0) Device is not responding to the request. Reset the device, and retry the operation.”

 

One would think, barring a hardware trouble, that there should be no way a core can block the IDE from entry to the core. The other cores on the DSP C6678 device can be halted and debugged. It is just the one core in this case which is unhaltable.

What causes this state where the IDE is unable to halt and control the individual core's execution?  How can i force the IDE to overtake the core's execution? 

  • 0 in reply to Betsy Varughese
    Prodigy 70 points

    Update:  If I disable  "Silicon Real-time Mode" on Code Composer Studio  (CCS) , I am able to halt the core. So the question becomes, what is it that is happening when Silicon Real-time Mode (let's call it SRM) is enabled which could cause the inability to halt the core? According to the CCS gui SRM enabled means "service critical interrupts when halted, allow debugger accesses while running". So I imagine that the inability to halt when SRM is enabled may have something to do with a "critical interrupt", but it's really not clear and the user is left without much helpful information from CCS.   I wish that rather than offering up a cryptic "Error - 1060",  that the Code Composer would instead provide some helpful information about whatever critical interrupt is running or something else useful, as opposed to blocking access.  And in my case, single stepping without SRM mode enabled does not reveal any further interrupts taken so the end result is that we currently unable to resolve the underlying issue that is being debugged.

    Also, in the previously discussed incidents that Betsy V had pointed above, the recommended resolution involved checking the JTAG connection and the hardware associated with it.  In my case, I can debug the device outside of the impacted core ( e.g., the other cores, and the memory, etc can be viewed) so clearly the JTAG connection is fine.  This seems to be some CCS limitation or C6678 device limitation with the SRM being enabled.  

  • 0 in reply to rick szajdecki
    TI__Expert 4220 points

    Hi,

    Could you please let me know which CCS version you are using?

    Regards,

    Betsy Varughese