• State Resolved
  • Locked Locked
  • Replies 18 replies
  • Subscribers 34 subscribers
  • Views 3006 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.

Tiva 129 NDCPT gives (Error -2062 @ 0x0) when connecting debugger

Raymond Mack
Expert 1575 points
Other Parts Discussed in Thread: UNIFLASH, CC3200

Hey y'all:

We have been fighting this for a week or more now.  Here is the text we get:

Error connecting to the target:
(Error -2062 @ 0x0)
Unable to halt device. 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).

Setting the TCLK to 0.5 MHz does not solve the issue.

Here are some bullet points:

1) Seems to work fine until we start running TI-RTOS and turning on Ethernet.  Bare metal apps do not see problem.
 If the problem comes and we can get back to bare metal, it boots fine, so we have a software config issue.

2) We *ARE NOT* turning on any part of port C (that we can tell).  Could be part of TI-RTOS or NDK, but I doubt it.

3) For a while we were able to juggle a hard reset and starting the debugger to get it to load, now it seems to get into a bad place very quickly.

4) Tried to download Uniflash version uniflash_setup_3.1.0.00026 but installing it gives an error that it is not compatible with CCSv6.  Running CCS:  6.0.0.00190 .  Seems pretty weird that a very recent version of CCSv6 would not work with this version of Uniflash.  Also, does Uniflash need a 64 bit version?  Didn't see one to download.  Could use this if I could ever get it loaded.

5) running the Test Connection tool in the targetConfigs tab gives the following:

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

This utility has selected a 560/2xx-class product.
This utility will load the program 'xds2xxu.out'.
The library build date was 'May 21 2014'.
The library build time was '18:02:25'.
The library package version is '5.1.507.0'.
The library component version is '35.34.40.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '13' (0x0000000d).
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]-----------------------------

This emulator does not create a reset log-file.

-----[Perform the Integrity scan-test on the JTAG IR]------------------------

This test will use blocks of 512 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 512 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 XDS2xx USB Emulator_0]

So, is there some other thing that can keep the debugger from connecting?  I am guessing that I may have an output connected to an input or some other really stupid configuration bug, but I can't get back to real control now.

As a head slap aside: doing Task_Sleep before you actually kick off the RTOS is pretty stupid and pointless :-)  I need to find some other way of delaying code once we get the clock set to 120 MHz.

Looking for words of wisdom.  (BTW, is JeanAnn still with the group?)

Ray

  • 0
    Guru 26105 points

    Hi,

    I can comment only for point 4): AFAIK there are two versions of uniflash - one is for CC3200, the other for the rest of the world - so take care what is to be downloaded. (I use both..)

    Petrei

  • 0 in reply to Petrei
    Guru 47900 points

    Does this occur only upon a single board?  Always helps - provides insight - to have 2,3 boards at the ready.

    JeanAnne has departed although she may occasionally monitor this/related space...

  • 0 in reply to Petrei
    Expert 1575 points

    Thanks.  I got the right one.  I got around the error by creating a c:\Uniflash directory and installing there instead of in my c:\ti directory.  The install works but the "unlock debug port" does not.

  • 0 in reply to cb1
    Expert 1575 points

    cb1- said:
    Does this occur only upon a single board? 

    Yes, sort of.  We have traded out MCUs several times and the problem is solved with a new MCU, but no, we only have just the one board for now.  This is a really good suggestion though.  Amazing that we still have pads on the board after 3 MCU swaps!!!


    Had the hardware guy do a couple of standard ARM JTAG things: added 10k pullups on TCK and TMS.  I have asked that the 1K pullup on reset be changed to 10k but he assures me he sees a good hard ground on the scope when the XDS200 yanks reset.

    I finally got Uniflash installed and running.  I had to install in c:\uniflash instead of c:\ti (where CCSv6 is located).  I tried the "unlock debug port" operation but when I use Uniflash to read the MAC address, I still get the -2062 error.


    I am pretty bummed now.  I presumed that the JTAG chain is able to clear FLASH with the ARM core held in reset.  Must have something really toasted in the MCU at his point.

    Ray

  • 0 in reply to Raymond Mack
    Guru 47900 points

    Feel your pain - always "frustrating/helpless" when you, "cannot connect!"

    May I suggest that you acquire the nearest Launchpad MCU board to yours?  We must assume that qualifies as "known good" - you may then attempt to connect (again) and this process may reveal weakness in your connection methods and/or the design/implementation of your custom board.

    Should the Launchpad "instantly/repeatedly" connect - your custom board has clear issues.  But - absent that clear confirmation - you're in a, "maximum randomness" state - where any/every item is suspect.  Methodical test, one by one elimination, likely will visit your encampment...

  • 0 in reply to cb1
    Expert 1575 points

    cb1:

    Love your descriptions! Maximum randomness sure fits!

    We have about 70 launchpads for the Tiva 129.  Bought to get us enough processors until they go to production which appears to have happened late last week.

    That is how we did the first few rounds.  We programmed a bare metal application on the launchpad and then transplanted the MCU to our board.  Looks like I may need to do one more round. (or maybe 10)

    We are lucky I guess in that we have two completely different designs using the same MCU.  This one is a "slave" processor among many and the other is the main processor on its board.  We have working code on launchpads and our other design.  This one is a real PIB.  It is obviously a hardware/software issue.  It is just tough not being able to regain control of JTAG.

    Did you work here in Austin? Did we work together at Conexant by chance?

    Ray

  • 0 in reply to Raymond Mack
    Guru 47900 points

    Visit often, conspire w/U of T, (have prof. friend - fly into Austin FBO) and past consulted @ Conexant.  No one could forget your name - nor mine - but as I'm involved in certain "restricted activities" - please hold to "long used - cb1." 

    Having known good - working boards - enables "sanity check."  Earlier you mentioned 10K pull-ups upon all (but TDI!)  Our small group "swears" by such at each/every JTAG pin - reliance upon internal MCU (too high resistance - we often find) often proves insufficiently robust - all operating conditions.

    May I suggest your creation of very small test program - again studiously avoiding (like the plague) Port C - and try to attach & then load that to fresh (i.e. liberated from launch board) MCU.  Should that fail - usual suspects are each/every power pin (incompletely soldered/missed), Reset circuit (perhaps R-C pulse too brief/missing), and/or JTAG short/open.

    You're resourceful - we use (paid) IAR & J-Link.  Hundreds report your issue - CCS (to my mind) has far to go to reach the robustness of IAR.  And - via more modern SWD - 2 gpio pins are freed - bent to our will. 

    Bon chance mon ami - small, small world...  (systematically reduce the randomness - success then visits...)

  • 0 in reply to Raymond Mack
    Guru 86745 points

    Raymond Mack said:
    The install works but the "unlock debug port" does not

    If my memory serves me right, I have read a post here before saying that the Uniflash unlock debug port does not work.

    Ty the LM Flash Programmer "Debug Port Unlock Utility", instead.

    - kel

  • 0 in reply to Markel Robregado
    Expert 1575 points

    Thanks for the pointer to try LMFlash.  It did not work either, but we cobbled up a "donor" launchpad board and it works just fine as a debugger for our other board.  LMFlash does not work with XDS200 as nearly as I can tell.

    Neither Uniflash nor LMFlash were able to get me back going so I am guessing the IC is pretty well dead in some fashion at this point.  Time to try another board with a fresh MCU. It is strange that the JTAG "test connection" works but the debugger can't connect.  As I said, likely a severely crippled IC at this point.


    Many thanks for all the pointers.  I'll report back if I ever find out what might be hanging the JTAG interface.  I guess  I will close this thread and submit a new one with results.

  • 0 in reply to Raymond Mack
    Prodigy 30 points
    We are having a very similar problem with our new board, did you ever find a solution?
  • 0 in reply to jess britt
    TI__Guru**** 244400 points
    Hello Jess,

    A lot of problems on JTAG are similar in symptoms but may have different root cause. Can you please open a new post to be sure we do not clobber an existing post. Also do mention the details of your new board and if possible do check the forum for similar issues (other than this post)

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1575 points
    Amit:

    Looks like you accidentally mashed the wrong button and replied to the wrong message this morning. I don't remember if we set up an answered question for this over on the RTOS forum.

    The good news is that I have a few words of wisdom on my original post just in case it is not captured elsewhere:
    1) *ALWAYS* build your hardware with a reset switch. If you get in this situation you will need it to get control with JTAG.
    2) When starting out, put a *massive* timing loop in main() that will burn cycles in bare metal mode for about 3 seconds. You need that time to press the hardware reset button after the JTAG resets your hardware so you can grab control.
    3) I am pretty sure we had a hardware problem on Ethernet that was causing the issue. Ours is admittedly a strange situation where we have a direct connection between an Intel Gigabit controller and the Tiva without magnetic coupling. All would work fine until we launched the Ethernet hardware. The problem was that the two 49.9 ohm terminators were pulled down to ground rather than pulled up to Vcc as the app note shows. Pulling the Ethernet transceiver pins the wrong direction will lock up the system!!!

    Ray
  • 0 in reply to Raymond Mack
    TI__Guru**** 244400 points
    Hello Ray

    Thanks for the details. Hopefully Jess has the exact same issue that gets resolved with your answer.

    However to clarify, JTAG not working is a very generic post on the forum and we would encourage the poster to be more precise on what the board is, which device, connections any software changes before it stopped working.

    Regards
    Amit
  • 0 in reply to jess britt
    Expert 1575 points
    Jess:

    Not sure if my last post got to you. I replied to something that was in another forum.

    Here are the words of wisdom on this issue:
    1) *ALWAYS* put a reset switch on the board. You will need it to be able to get control back for JTAG if your system ever gets to the point where JTAG just mysteriously goes away.
    2) Put a massive timing loop as the very first thing in main() to keep it running just the CPU in bare metal mode for about 3 to 10 seconds. This allows you time to hit the reset switch and *then* launch the debugger. The debugger can attach while the CPU is running but not when the hardware is locked up.

    Our issue was actually a hardware issue if I remember correctly. Our system is weird in that we connect an Intel Gigabit Ethernet controller "directly" without transformers (capacitors instead). We pull the balanced 49.9 ohm terminators to the rail. Our problem turned out to be that we were pulling the Ethernet pins down to ground rather than pulled up to Vcc as shown in the app note. Fixing that cured our Ethernet issue. For some reason, as soon as the Phy would start, the entire chip would go nuts and JTAG would stop responding. As long as we left out the Ethernet initialization for NDK, the system would work fine.

    We also found one other issue that is captured somewhere in the forums:

    There is a race condition between EMACSNow.c and the rest of the Ethernet initialization. We had part of our initialization happening in one of our RTOS tasks and the rest would happen when the main NDK threads would get a chance to run. We were initializing the the Phy database in our thread and then the NDK start up would come behind and clear out the database. It made for "interesting times".

    Again, that is captured elsewhere in the forums and TI is looking at what to do about it. If I remember correctly, you need to make sure that you start NDK *before* you start any of your threads that will interact with the network. I believe we started our tasks in the Net_init_hook so that NDK was settled before we started our stuff. It was weird because we have two similar systems based on the Tiva 129 with very similar system designs, but not exactly. One system had just the right timing that the network always came up and worked. The second always hit the race condition wrong. Go figure...

    Ray
  • 0 in reply to Raymond Mack
    Prodigy 30 points

    Thanks for the update Ray,

    We just started to look into our issues and I thought it would be nice to see if you had solved your problem as it might lead to us troubleshooting ours. We will look into the things you mentioned.

    If the problem persists, I'll make a new thread at Amit's request as it makes the most sense.

    Thanks again!

  • 0 in reply to Amit Ashara
    Prodigy 30 points
    If the problem persists after today, I'll make another post detailing our issue. I was just really curious to know what the final outcome was to this post.

    Thanks
    Jess
  • 0 in reply to jess britt
    Intellectual 280 points

    I came across same problem as I tried everything on this forum even replacing controller. but nothing work. Only way I could make this work was replacing Crystal.

    I was measuring crystal frequency for accuracy and validation purpose and at some point crystal died or I may have killed accidentally.

  • 0 in reply to Raymond Mack
    Prodigy 100 points
    Hi all,

    I have find this problem (Error connecting to the target: (Error -2062 @ 0x0) Unable to halt device) twice, with custom boards using a TM4C129 with TI-RTOS.

    Both times I got there in these scenario:

    Developing and debugging with CCS, with the Tiva connected in CCS Debug Mode, I kept on making changes, building and reloading new programs a few times each day, without powering off the board until the end of the day. Everything seemed to work as expected and I went home happy and satisfied with my work :)

    But next day, when powering on the board and trying to connect again and keep on working on my program, "Error connecting to the target: (Error -2062 @ 0x0) Unable to halt device" appeared.
    To bring boards back to life, I had to try about 10-15 times to push reset button and Retry connection with CCS Debug while simultaneously releasing the reset button until it connected again. Once finally connected, a CPU Reset and a safe program Load brought the Tiva out of this locked state.

    I guess I had to connect just between the release of Reset button and before the program entered to BIOS_start(); I still don't know the lockup cause, but it is likely to be Ethernet-related.


    So, Ray's proposed solution will make bringing the Tiva back to life much easier in case of a processor software locking problem:

    1) *ALWAYS* build your hardware with a reset switch. If you get in this situation you will need it to get control with JTAG.

    2) When starting out, put a *massive* timing loop in main() that will burn cycles in bare metal mode for about 3 seconds. You need that time to press the hardware reset button after the JTAG resets your hardware so you can grab control.



    Regards,

    Carlos