CCS/EK-TM4C129EXL: Error connecting to the target

Sara Fernandez said:

At some point, I connected the USB to test the communication and wanted to debug. Since then the CCS Shows: "Error connecting to the target"

So, so many end up here  in "just" your situation.      (yet vendor "finds the time to KILL LIKE - and AVOID this KNOWN/ON-GOING ISSUE!)

You do not describe, "How you connected the USB to test" - there are more than 1 USB port on your board - which did you use?"

Feel your pain (yet we avoid your MCU) and it is hoped that vendor will "Deal w/REAL ISSUES" - rather than "Wasting time/effort - on (very) poorly conceived "forum down-grades!"

The "Recovery Process is "quite detailed" you must follow vendor Charles' instructions - exactly.    (especially the (admittedly) cumbersome "hold of Reset.")

If you're "with a firm" perhaps one there has a "real/proper JTAG/SWD probe (J-Link)" -  that probe proves "surprisingly EFFECTIVE" in recovering such "DEAD MCUs!"

The J-Link Probe was introduced long before vendor "attempts" - is notably more complete/complex - and firm/I have (on multiple occasions) restored "your class" MCUs to operation - via its utilization!     (this is a "real J-Link" - running Segger's comprehensive software - outside of  "vendor limitations..."

There (must) be a reason for its, "World's Top Selling/Delivered JTAG/SWD Probe" - might that be true?

What do you - and literally "hundreds before you," share in common in such JTAG lockout?"      (that's a worthwhile search path - is it not?)

Hi cb1_mobile,

unfortunately I dont have a J-Link JTAG to test it out :(

Hi Charles,

1. I dont release the reset button when power it on, and follow the instruction comming from the LM Flash Programmer. Here a screenshot after releasing reset:

2. I power cycle the board and the process is successfully finished

.

3. A new EK-TM4C1294XL is on the way. When it gets here, I try it and inform you.

4. I have a XDS100v2 and already tried with CSS and Uniflash to erase the flash or to download a new firmware. I get with both also an error. Here an screenshot of the error showed by Uniflash:

5. I used the dbgjtag.exe to unlock the board:

I still cannot unlock the board...

Thanks a lot for your help,

Sara

Hi Sara,

 Sorry to hear that the device is still not yet recovered. Not sure what the root cause is. From the screenshot the MAC address is all F's. So it seems the unlock was successful but you still cannot connect to the target. If the unlock was truly successful then it means the jtag was ok because the unlock sequence needs to manipulate the jtag interface to scan in unlock patterns. Was the MAC address already F's before you had any problem with the board. if the MAC address changed from non-F's to all F's then the unlock was successful.

 While you are waiting for the new board can you check:

 1. On the problem board if the VDD and VDDA supply rails are 3.3 V. Also check with a digital multi-meter that the VDDC rail is 1.2 V.

 2. Since you have XDS100, you can run a scan test in CCS. See below.

 Let's know your result with the new board arriving.

Hi Sara,

 Can you take scope capture of the JTAG interface. Below is what I capture (TCK, TMS, TDI, TDO) when running the connection test. What do you see on the TDO?

There are numerous potential "causes" of such difficulty.      Unknown is the existence of any "external connections" between poster's failed board and the "outside world."      While the MCU manual "suggests" that, "providing input signals to the unpowered (or incompletely powered) MCU" - appears to be acceptable (under some conditions) my firm much prefers, "Prevention of such signal arrivals - when the MCU is unpowered."     This strategy places "signal & power discipline" above, "hope & prayer."     (Not that there's anything too wrong w/ "hope/prayer" - other than their "minimalization @ the finest engineering schools.)

Our firm takes the additional safeguard of employing small value series resistors upon each JTAG/SWD line.      And - as long noted here - use of external pull-up Rs - an order of magnitude lower in value than the MCU's (free) internal Rs - which is proven to produce more robust signalling while providing (some) input protection.

ESD is a "convenient" catch-all when problems arise.      As semiconductor geometries shrink - ESD's potential for mayhem increases.       One must employ, "Proper ESD management - throughout each/every step in the component arrival/unpacking - auto placement & reflow - and "finished board" Test/Verify."       Note that "not always" will ESD damage reveal its presence - immediately!     In user's case - damage may have occurred anywhere - even repeatedly - along the unpack/place/reflow/test chain.      Often the ESD destruction "grows & extends" - (while not "yet" being noted) which complicates the discovery of  the "critical, earlier, ESD (time & place) arrivals!"      (which in time - doomed user's board...)

Also unknown is the "Destructive Potential" of the programming/debug tools - which are "minus the "substantial history & long-term success" of better known - and far more capable & extensive such tools. The fact that these newer/less capable vendor tools (appear) to work -in no way removes them from, "Prime Suspect" or from, "Aiding & Abetting" (i.e. being complicit in) the "Lock-Out issues" - unfortunately reported - with great & ongoing regularity - right here...  

This explains why several here have suggested use of, "Better known & more capable programming/debug tools" - which have a far longer & rich history - and have the power conferred by being "vendor agnostic" - indicating their superior depth, development and reach...      Removing one of the "potential sources" of such (dreaded) Lock-Out IS KISS compliant - and provides (some) positive movement - (i.e. the apparent (only) movement) towards issue resolution...