• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 2423 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/TM4C1294NCPDT: TM4C1294 Problem with XDS100V3 debugger: Error -233, 'SC_ERR_PATH_BROKEN'

Jesper Carlsen
Prodigy 80 points

Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: UNIFLASH

Tool/software: Code Composer Studio

Dear TI users,

I have a problem with the TM4C1294 and XDS100V3 debugger, that occured this evening, after weeks of succesful testing & debugging.
I have a PCB with the microcontroller on, that is interfacing via the ARM 20 pin connection to an XDS100V3.

My configuration in Code Composer Studio is as following:

This configuration has been working for me, for the last few weeks, as stated above. Suddenly during testing today, I was not able to recover a JTAG connection to the device. I did not experience any kind of issue before or after, suddenly it just did not connect. I did not suspect any electronics to have been destroyed, since I was testing a product inside a sealed box.


The most weird part is, that the microcontroller is running it's program, as it should. But I cannot debug/flash new software onto it.

I have tried my XDS100V3 with an earlier version of the PCB, with same configuration, which worked. Therefore I have a hard time believing the issue is my debugger probe. I also have a hard time believing the microcontroller is damaged, since it runs its program nominally, when I power the device.

The error message I get is as following, when I run a test through CCS:

The value is '-233' (0xffffff17).
The title is 'SC_ERR_PATH_BROKEN'.

The explanation is:
The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
An attempt to scan the JTAG scan-path has failed.
The target's JTAG scan-path appears to be broken
with a stuck-at-ones or stuck-at-zero fault.

[End: Texas Instruments XDS100v3 USB Debug Probe_0]

I have read some posts on the topic, suggesting that it worked after changing the microcontroller. That is however not sufficient to me, since I would like to know what is the error, and whether anyone succesfully solved it, without trashing the PCB.

  • 0
    TI__Guru 72500 points

    Is it possible that in the last version of your program that was successfully flashed into the device, you disabled the JTAG pins? If so, you can unlock the device from the CCS7 "On-Chip Flash" window. It will erase the entire flash contents including the "User Registers":

  • 0 in reply to Bob Crosby
    Prodigy 160 points

    Dear Bob,

    Thanks a lot for your comment. I did try to unlock the microcontroller via the XDS100V3, it does however seem like it does not support it? I tried through LM Flasher, Uniflash and CCS. Only through LM Flasher, it seemed to work, giving me status succes, but without erasing/unlocking the microcontroller.

    Afterwards I tried to use the ICDI debugger on the TM4C1294XL evaluation board, by desoldering 0-ohm resistors on X1 and using the U6 debugger out probe. This was needed, for unlocking the MCU via either Uniflash or CCS. Again, without succes.

    I tried to use the ICDI debugger on my old version of the PCB, and again it proved to work. So again I can assume, that the connection is established correctly.
    I am very curious to hear other suggestions, since I hope this problem will not occur repeatedly, if I decided to change the MCU.

    My MCU is still running its current program without issues. When flashing that same program to the TM4C1294XL evaluation board, I do not have any issues in reprogramming the board.

    Hope I am clear and that someone else can help out. 
    Best regards,

    Jesper

  • 0
    Prodigy 160 points
    I have measured the TDI, TDO. By default these are low on my faulty board. Whenever the first debug initiation has been run, the TDI pin goes high. The TDO pin stays low.
    On my other board, the pins are both high by default. I am wondering what could make the JTAG pins behave like this? It does not seem to be a short between ground/vcc/the pins, and the TDI pin can transition between GND/VCC, but in a bit strange manner.
  • 0 in reply to Jesper Carlsen
    Prodigy 160 points
    Dear everyone,
    We did not manage to find the solution to this strange problem. The MCU has been changed, and now there is no issue however. I am just waiting for the next time this will happen. Hope to see others with same issue debating this, since I have seen various people talking about it, but always without a clear answer in the end.

    Best regards,
    Jesper
  • 0 in reply to Jesper Carlsen
    Guru 117855 points

    Unstated is the connection interface (in its entirety) between your JTAG Probe and your (suspect) board.     Such may be important - especially as you, "await the next occurrence of this unwanted event."

    Our firm has (frequently) noted such occurrences when the MCU's (internal) pull-up resistors are employed - rather than (far lower value - thus more proper) external resistors - placed close to the JTAG pins.    In addition - small value, "JTAG series resistors" add protection to the MCU.   (56-100Ω have worked for our clients)

    The "too high" value of MCU's internal resistors (may) work in lab/undemanding conditions - yet are (always) subject to signal rounding & reflections - most always present w/in the "real-world."    As cells/tablets expand their presence - and radiate - unwanted RF may also prove causative.    Lower value pull-ups (EXTERNAL) provide superior performance & may "safeguard!"

    You may further consider use of a renowned JTAG Probe (J-Link) which proves "vendor agnostic" (ALL ARM MCU brands welcomed) and has a much greater "history of success" than (lesser) devices from individual vendors...   (i.e. those not IN the JTAG Probe business for (nearly) as long - or w/such "focused" expertise & resources...)

    Firm/I "share your uncertainty" (perhaps even fear) over the "mystery fix" - and its ability to offer "long-term" MCU health/comfort.     Tips herein prove "more active" in resolving such weakness...   (simply replacing the "bad" MCU (appears) to "ignore" the cause - thus this posting in your behalf...)