• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 31 subscribers
  • Views 8132 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.

TM4C1294NCPDT: JTAG Error -2062, error connecting to the target. Full checklist and questions.

Bruno Saraiva
Guru 13040 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: UNIFLASH

This post is about a custom board with a TM4C1294NCPDT. This product has just gone into Revision B, and the JTAG connections are a copy/paste of the same schematics successfully used in many other products of the company.

A batch of 5 boards was produced, and none of them will accept the JTAG connection for firmware transfer and debugging.

The following "emulators" or probes were tried:
- IDCI from a TM4C1294 Launchpad
- XDS100v2
- XDS200
All of these pods properly apply firmware and debug other boards with similar configurations.

The following software was tried to connect to the boards:
- Directly from CCSv7.1
- LMFlash
- UniFlash

The error on CCS is:
"CORTEX_M4_0: Error connecting to the target: (Error -2062 @ 0x0) Unable to halt device."

Trying to apply the unlock solution from UniFlash or LMFlash did not result.

The following was tested on HW level:

- Power into the MCU is confirmed 3.3V on all of the VDD labeled pins, namely 7, 16, 26, 28, 39, 47, 51, 52, 69, 79, 90, 101, 113, 122. VDDA and VBAT are also on the same power bus at 3.3V.
- No neighbor pin is shorted or showing 3V3.
- VREFA+ is powered by 3.0V
- All GND/GNDA pins were checked for shorts and confirmed to be properly connected to ground, namely 10, 17, 48, 55, 58, 80, 114.
- The VDDC lines are measure to be ~1.2V as expected.
- #HIB is floating
- #WAKE is WPD to GND via 10K
- #RESET is WPU to 3V3 via 10K and into a board's reset button as well as to JTAG reset line. The other end of the button is connected to GND, and pushing the reset button properly brings the #RESET line to GND as expected, suggesting that there is nothing "locking the reset high".
- TMS, TCK, TDO, TDI, GND and VTARG are all double checked to their respective MCU pins and into JTAG connector.
- Board current without firmware and no other functions enabled are within reasonable, at 30mA.
- No unreasonable voltage on any of the other pins of the MCU.

Using a scope on TCK, I can see an initial nice train of pulses on TCK, with square edges and true at 1MHz. Then it stops for a while and try again, before dying. There was no time today to view the other signals.

We do not use WPU's on the JTAG lines - never used, never had a problem - but recently accepted the suggestion and will do from now on. On two of these boards, we added 4 WPU's (3K3) on TMS, TCK, TDO, TDI. To no avail.

As I write this, I'm reading the JTAG document spma075.pdf. The following aspects are learned and are different from the current status:

- JTAG pull-up resistors shall be 10K, not 3K3.
- The pull resistor on TDO is actually PULL-DOWN, not Up. Some non-official comments on the forum mislead this information.
- There shall be no pull-up on TDI

If the above fixes don't solve it, the following can still be done:
- Check at OSC0 pin that the crystal is properly oscillating.

- Make sure RBIAS resistor is properly populated... We DO NOT have RBIAS resistor, for this board does not use Ethernet. Datasheet says that preferred practice for unused RBIAS pin is NC. However, yes, there IS a 25MHz crystal into OSC0... Question 1: Could that be this exact problem?

Question2: where can I find the meaning for ERROR -2062 and other JTAG error codes?

More later, hopefully tomorrow.

  • 0
    Guru 117855 points

    Neither 3K3 nor 10K "qualify" as WPU! (WPUs are the province of the MCU's internal Rs - usually 40K or higher - which "welcome" signal reflections & rounded edges)

    Under SWD - we have had (near) 100% success w/10K pull-ups upon SW_Data & SW_Clk.   This when used w/ARM Cortex: M0, M3, M4 & M7 MCUs - from four vendors!

    We can demonstrate multiple boards well operating - this vendor & others - NOT pulling down - but pulling-up, TDO!    And - is it not true - that your "many other products" all used the MCU's WPU resistors?   Note that the, "Use of a pull-down" suggests that the specific JTAG signal may (only) pull or float "high" - thus relying upon the pull-down to support a logic "low."   (while "sometimes true" I do not believe that TDO must "always & only" be "pulled down.")

    Are you SURE about allowing #HIB to "float?" (unless that pin is "internally" pulled to a proper level - I'd be suspicious)

    While your post states, "FULL Checklist" - it does NOT mention a thorough read/review of the most recent  MCU errata!    And that leads directly to: Question 1:   Could that be this exact problem?    YES!
    I can long recall vendor's Amit advising users to ALWAYS populate that RBias resistor when employing a 25MHz xtal - just as you do!     That's the very first thing I'd add. (one hopes you provided a board footprint for that device!)

    You may note that the more mature/capable "J-Link" provides far more "error detection & reporting codes" than the cryptic and (not too helpful) ones - you and others - have encountered under vendor's "ICDI"...  (I Can't Debug Impasse!)    (multiple Like's should arrive for that...)

  • 0
    TI__Guru**** 191296 points

    Hi Bruno,
    Did you run a scan connection test?
    Can you even connect to the DAP?
    All five boards have blank devices, right? In other MCUs I worked with before, the debugger can fail to connect if the device has no clock (turned off by user code) or the code creates some rapid fault exception that prevents the debugger from connecting. However, this theory will not apply to your boards with blank devices.

  • 0 in reply to Charles Tsai
    Guru 117855 points

    Might you note the past (2013) assistance we provided you - in the "cure" of (yet another) JTAG lockout?

    e2e.ti.com/.../302620

    In that case we identified your imposition of a 1K resistor between your 3V3 supply and VDDA as the issue - you removed that resistor - et voila - JTAG commo was restored!

    Old habits die hard - might that past resistor (still) lurk?

    [edit] Your issue appears to be a well known "errata" listing - directing the installation of (dreaded) RBias - even when NOT employing Ethernet...

  • 0 in reply to cb1_mobile
    Guru 13040 points

    cb1_mobile said:
    Under SWD - we have had (near) 100% success

    I got curious about your preference for SWD already, and will try it when possible. Haven't researched the details, but while we are at it, I wonder if CCS supports that. Further, as also mentioned earlier, I plan to test my yellow JLink, and again I wonder if CCS will support it? The one I have is yellow, marked IAR Systems, with the 20-pin arm jtag connector for output. If your next suggestion is "move BACK to IAR", then I must say that will take a long while to happen!!!

    cb1_mobile said:
    Are you SURE about allowing #HIB to "float?"

    I guess I am. Page 1817 of current datasheet: "Connections for unused signals", #HIB @ pin #65 has NC as accepted practice and preferred practice.

    cb1_mobile said:
    "FULL Checklist" - it does NOT mention a thorough read/review of the most recent  MCU errata!

    You are correct. Readers, do read ALL the answers on the thread, for the initial (long) one was not born with the intention of containing the full picture, but rather to show what had been done and get valuable input from fellows. Note to self, go read the errata!

    cb1_mobile said:
    I Can't Debug Impasse!

    Always a poet! Feel free to acronymize XDS100v2 and XDS200 as well!

    Cheers

    Bruno

  • 0 in reply to cb1_mobile
    Guru 13040 points

    cb1_mobile said:
    might that past resistor (still) lurk?

    Nope! Stray resistor has been wiped from this planet.

    Hey, great to read "good old times" post, thanks again for the ongoing support. I do recognize it and hope to be able to pay it back somehow, as you know!

  • 0 in reply to Charles Tsai
    Guru 13040 points

    Greetings Charles,

    Charles Tsai said:
    Did you run a scan connection test?

    Yes, it reports "all good".

    All boards are blank. To be confirmed on Monday - we can't reach those boards today - but I do believe the culprit is the non-predicted RBIAS. Too bad "I just wanted to clean up the schematics", removed the Ethernet circuit (from Revision A into B), and by extension, followed the datasheet misleading "NC" for unused signals.

    Had it been easy, and anyone could make it work!

    Bruno

  • 0 in reply to Bruno Saraiva
    TI__Guru**** 191296 points

    Hi Bruno, cb1,

     I agree with both of you that RBIAS is a very likely culprit considering the errata.

  • 0 in reply to Charles Tsai
    Guru 13040 points

    Gentlemen,

    Thank you for the support!

    Glad to say that adding the resistor to RBIAS pin brought the MCU back to full life.

    Regards

    Bruno

  • 0 in reply to Bruno Saraiva
    Guru 117855 points

    Ay Caramba!   (in honor of one Bartholomew Simpson)    That's not TOO Ugly!    (always provide a pcb footprint - even when - AND ESPECIALLY WHEN - you're "sure" the part won't be needed!)

    So - how about "Greenies" for yourself, myself - and later arriving, vendor Charles - all who identified that RBias "savings" as unwise!

    And (special offer) for 100 (USD) staff/I will not forward this hi-res photo to your client.

  • 0 in reply to cb1_mobile
    Guru 117855 points

    cb1_mobile said:
    Question 1:   Could that (absence of R_Bias resistor) be this exact problem?    YES!

    Above is a, "true copy" from the first response to this thread.    

    As (you) had already identified the "possibility" of the missing resistor as failure's cause - it seemed (unnecesary) to provide the MCU manual's (confirming) citation.

    The (proper) release of "Green" to that, "First arriving post" is well indicated...

  • 0 in reply to Bruno Saraiva
    TI__Guru**** 191296 points
    Glad your problem is solved!
  • 0 in reply to cb1_mobile
    Guru 13040 points

    cb1_mobile said:
    ESPECIALLY WHEN - you're "sure" the part won't be needed!

    True... I tend not to provide reserve footprints, but it is about time to change this behavior...

    cb1_mobile said:
    for 100 (USD) staff/I will not forward this hi-res photo to your client

    Threat?  :o

    Client has absolutely no clue what these boards do... don't even know if we design/make them ourselves, or if they come from a magic cave underneath Disneyland grounds. All he cares for is that the track inspection gets done!   ;)

  • 0 in reply to Bruno Saraiva
    Guru 117855 points
    Friend Bruno - "threat" - that's SO unkind/unexamined. Think instead of an "opportunity." (negativity leads to compressed inspiration - similar to improper "withhold" - of earned Green - by your fast arriving "first" responder.)
  • 0 in reply to Bruno Saraiva
    Guru 13040 points

    Bruno Saraiva said:
    Feel free to acronymize XDS100v2 and XDS200 as well

    Xtreme Debugging Sorrow?

  • 0 in reply to Bruno Saraiva
    Guru 117855 points

    My friend - you have now earned "Membership #2" to the esteemed, "Escape forum boredom via originality" club.

    Is it not true that (only) the very new - or otherwise "unknowing" - would choose such (little known & highly restricted) (i.e. compromised) device - when the "World Leader" - with a spectacular history - is in stock & available at (great) "Educational discount?" (and one does not even have to "pretend" to be student/educator...)

    And - has it been (really) established that the extreme number of JTAG "Lockouts" (noted here, daily) have not been induced or "aided/abetted" by such (less than Stellar ... clearly I deserve "Likes" for that) devices?

    At some point - forum users may "grow" - seek another's ARM MCU - and hallowed XDS (and friends) will "Lock them out, too!"    (as they serve ONLY 1 vendor - delightful...)