Programming Tiva C LaunchPad with XDS200

Hi Amit,

Thanks for the link.

Yes, I am selecting the XDS200 in both CCS and UniFlash

I cannot see the option for Adaptive Clocking in UniFlash anywhere, nor in CCS.

I have added 3.3v via a 100Ohm resister to VTref.

I am following the instructions outlined at the following page for the Debug In option - http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To

I still get the exact same error message.

Glenn.

Hi Glenn,

In the CCSv5 where you have selected the Emulator, there is a Target Configuration. When you go there the root of the connection path would be having it. As an example I have attached a snapshot. The property name is "The JTAG TCLK Frequency (MHz). Do not select Adaptive Clocking Mode but instead use the Fixed option.

Also please do go through the TIVA-C Launchpad Design Document on the TI website. There may be additional jumpers to connect or unmount.

Amit

Thanks Amit,

Mine is already set to "Fixed with user specified faster value" and this value is 10.0MHz

When I run the Test Connection I get the following output.

[Start]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]

-----[Print the board config pathname(s)]------------------------------------

C:\Users\glenn\AppData\Local\.TI\4084209646\
0\0\BrdDat\testBoard.dat

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

This utility has selected a 560/2xx-class product.
This utility will load the program 'xds2xxu.out'.
E_RPCENV_IO_ERROR(-6) No connection: DTC_IO_Open::dtc_io
Failed to open i/o connection (xds2xxu:0)

An error occurred while soft opening the controller.

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-250' (0xffffff06).
The title is 'SC_ERR_ECOM_EMUNAME'.

The explanation is:
An attempt to access the named emulator via USCIF ECOM has failed.

[End]

The Tiva C LaunchPad has pins available for JTAG debug, it is integrated into the design. The XDS200 is designed by TI. My guess is that there is someone at TI that knows exactly how to hook the 2 up together. I am going to wait to hear from them...hopefully soon :-) rather than do all this trial and error.

Has anyone from TI or anyone who has both, connected these 2 together successfully?

Glenn.

Hi Amit,

My bad, I just realised you are from TI !!

I have performed the following suggestions but still get problems.

• I have set the clock to 2Mhz and 0.5MHz (thanks for the suggestions Petrei)
• I have shorted C34 (Thanks again Petrei)
• I have ensured that adaptive clocking is not being used.
• I have added 3.3v via a 100Ohm resister to VTref.
• I am connecting directly to the CTI20 Header 
• I have review http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide
• I am following the details outlined here for DEBUG IN - http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To
• I have read the Tiva C user manual.

When I run the Test within CCS I get the following error message. It is also the exact same error message I get when the LaunchPad is turned off (i.e. I have no power being supplied to the LaunchPad).

Please note, this is a different error message, so things may have progress. But I think all that was done was rebooting CCS to change the error.

[Start]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]

-----[Print the board config pathname(s)]------------------------------------

C:\Users\glenn\AppData\Local\.TI\4084209646\
0\0\BrdDat\testBoard.dat

-----[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 'Aug 20 2013'.
The library build time was '23:33:52'.
The library package version is '5.1.232.0'.
The library component version is '35.34.40.0'.
The controller does not use a programmable FPGA.

An error occurred while hard opening the controller.

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-183' (0xffffff49).
The title is 'SC_ERR_CTL_CBL_BREAK_FAR'.

The explanation is:
The controller has detected a cable break far-from itself.
The user must connect the cable/pod to the target.

[End]

I am using jumpers to connect the board, I have done this by soldering headers to the LaunchPad to ensure a solid connection, I have also tested to ensure that there are no issues between the board and the end of my jumpers. I have then inserted the jumpers directly into the CTI20 Headers, which seems to create a firm connection (though I cannot test this

I am performing these tests, as I have a custom board on its way and I want to ensure that I know where the problems lies should I have problems with my board. 

Questions:

Do you have an XDS200 and a Tiva C LaunchPad to test this setup?

If so, can you at least test the XDS200 and see if you get the same error message I am getting when not connected to a target board? (I am concerned there is something wrong with my XDS200)

Can you confirm whether I connect Reset (On LaunchPad) to the nTRST (CTI20)?

Thanks!

Glenn.

Hi Glenn,

Some information can be useful for me.

Can you let me know which XDS200 Emulator Model is it? I have had issues where without the description I ended up using the wrong Manufacturer and Make.

Also are you using DKTM4C123 or DKTM4C129?

Connecting Reset on the Launch pad to nTRST is not mandatory.

Also the cable break far would indicate that there is something at the target end. Also on close inspection the header information mentioned earlier on the thread indicated that you had a ARM20 header on XDS200 which is connected to the CTI20 header on the board. They cannot be mapped as is and that is why I believe you are doing the wiring? Please correct me on both ARM20-CTI20 and wiring aspect.

For the latter can you please send across a rough diagram/picture of the setup from XDS200 to the LaunchPad and where is what in the path? Sometimes a visual image is needed?

Amit

Hi Amit,

I just purchased the Spectrum Digitial XDS200 USB Emulator from the TI website here - https://estore.ti.com/TMDSEMU200-U-Spectrum-Digital-XDS200-USB-Emulator-P4281.aspx

 I have opened it up and it says REV B on the PCB. 

I am using the EKTM4C123G (The Tiva C LaunchPad).

Yes, I am having to wire it up. As the LuanchPad just has a few VIAs to use for JTAG programming. I have soldered headers into these VIAs and then used jumpers.

I have got rid of the ARM20 Adapter and am now connecting directly to the CTI20, I have double checked the pin numbering (One side has odd numbers, one side has even numbers (the key is on the even side)).

Here is the diagram

<removed diagram due to error>

And here is the photo of the setup

<removed picture due to error>

I hope I have done something wrong! :-)

Thanks,

Glenn.

Should your earlier EXT DBG handling (tie to GND) prove correct - and instead it is pulled up - output contention between the ICDI MCU and your new JTAG probe may result.

Never good - if you're especially unlucky - both sides may be damaged.

Thanks Amit and cb1_mobile,

We are in business. I am now debugging my Tiva C LaunchPad with the XDS200 and it is pretty fast.

Running the test returns this - "The JTAG DR Integrity scan-test has succeeded."

I believe the issue was related to me not getting the pins right when I was using the ARM20 Adapter, I didn't follow the odd one side even the other side setup.

I corrected this when I moved to the CTI20, but this will not work for the LaunchPad as there is no TDIS.

Regarding the VTref mistake, that was just made for the photo and diagram, as I just quickly put this together...and It's late here in Australia! :-)

So do not use the CTI20 connectors, use the ARM20 Adapter and make sure you check the pin numbers...doh!

Glenn.

p.s. Cb1_mobile - I am doing this on the Tiva C LaunchPad, as I have a custom board on its way and I want to ensure at least one issue (the programmer) is covered should I have issues. 

@ Amit,

Good job!  I continue in the belief that hook-up shown ran counter to the "disabling verbage" of ICDI MCU. 

Glenn's writing is not yet clear enough (imho) - and I believe that it is wise to "nail this issue down" so that others don't suffer needless loss of MCU and/or JTAG probe damage due to, "signal contention."  (i.e. both sides output & connected!)  Verbage in question, below:

Should your earlier EXT DBG handling (tie to GND) prove correct - and instead it is pulled up (as is illustrated - your drawing) - output contention between the ICDI MCU and your new JTAG probe may result.  Never good!

On a separate note:

The assertion of, "Far cable break" seems sub-optimal - I submit that a break 0.1mm from the XDS (hardly "far") would trigger the exact same (inexact) diagnostic!   Words/language have meaning - "cable break upon TDIS signal line," seems both a more valuable & appropriate diagnostic reporting...  (know that this is not your creation - but the opportunity (perhaps even "motivation") exists now - for correction/improvement...) 

@ Glenn,

Hi back - surely your care & effort will be appreciated by other XDS and/or similarly equipped others - thanks.

Poster Amit received green Verify for (apparently) his TDIS (pin 4) assertion - which is completely absent - your most recent writing.  Are you stating that no connection or special handling is required for this TDIS signal?  (if that's the case - how did Amit's Verify result - might this not confuse the multitudes?)  And your later post claims that there is no TDIS signal capability w/in your launchpad!

Your GND pin sequence "double includes" pin 10.  (last entry should be pin 20)

It may be best if you [edit] away your earlier diagram showing EXT_DBG routed to 3V3.  (potentially enables/insures signal contention - launch's ICDI MCU and external JTAG probe)  I properly noted (and squawked) about that miscue!

Suggest that green Verify be "properly" awarded to yourself...  (for creating the minimum required, "documentation") 

To be certain - Amit's assistance was most helpful but may not have "fully risen" to heralded, "Verify" Status.

Hi cb1_mobile,

I have made the suggested edits....you have such attention to detail! very impressed.

I have also edited the wiki to point to this discussion, so that others will have some more information when they wish to perform DEBUG IN - http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To#DEBUG_IN

I assumed that changing connectors was required, as the CTI20 Header requires the TDIS (GND). The ARM20 Adapter does not include this, but on closer inspection it does include a small circuit with a few resistors, I am assuming this provides the required routing mentioned by Amit....not sure?

Glenn.

I have an important question regarding my board design, that refers to what has been discussed above.

The following was one of the essential connections:-

 3.3v ---100 Ohms ---> VTRef (pin 1)  (Basically connect the 3.3v on the LaunchPad Board via 100 Ohm resistor to the VTRef of the ARM20 Adapter)

Does this mean I need to add an 100 Ohm resistor in my board design ?

What would happen is the 100 Ohm resistor is not present ? (I can test, but if it could break my emulator, I'd prefer not to test)

Glenn.

@ Glenn,

First - thanks for your (proper) multiple Verify awardings.  TI'er Amit & outsiders Petrei & I all thank you.  (yet somehow - you failed to include film, "Gravity" in such awards - famed Academy, earlier today, corrected that oversight...)

Now - have you a schematic which reveals "guts" of your new JTAG probe & that ARM20 adapter?  Might you link or embed, here?  Unknown is how - or if - that 3V3 is used by your probe/ARM20 adapt.  Should that 3V3 be powering the probe - 100R may be bit high.  Would not your use of a DVM to measure the "drop" across that 100 ohm R prove useful?  Suspect that 3V3 is either providing (some slight) power or is providing a simple, "presence signal" - alerting the JTAG probe that your target board has, "landed."  (Pardon - but Gravity is still bit, in the newz!)

If it were me - always "safe" beats "sorry."  Simply place a 06-03 (or suitable) board plot for that 100 ohm (or 0 ohm) R.  That covers both of your bases - and may, "save the day" later - should you change JTAG probes.  Note that our group always provides direct (no R) connection between 3V3 and our J-Link (JTAG/SWD) probe.

Indeed I do.....please see attached PDF for Schematics -  <removed>

I am using Tag Connect as the connector for programming....not a regular JTAG.

More info on Tag Connect here - http://www.tag-connect.com/

And this links to the ARM20 to Tag Connect 2050 Adapter pin outs - http://www.tag-connect.com/Materials/TC2050-ARM2010.pdf

Glenn.

You're a bit quick for this reporter!  Plz give a re-read to my final pass - one up posting...  I'd stick a "spot" for the R - you can simply jump, insert 0 or insert 100, or other ohm as/if/when needed...

I may misinterpreted your request....and you asked for the schematics of the XDS200. I believe TI only makes these available to their Emulator partners.

I am about to test this with my LaunchPad without the 100Ohm. You see the board is already in production, and I need to make sure this will work, or make the changes and get some new boards made.

I will report back on the results for all.

Glenn.

Doubt that harm will result w/100 ohm in place. 

Again - by measuring the "V drop" across that 100 ohms we'll know the current draw.  That will provide great clue as to whether the 3V3 is "powering" or simply announcing, "presence" of a target board.

Everything worked without the 100 Ohm resistor.

I was unable to measure the voltage drop, my multimeter decided to stop working. I will not tell you how much I paid for it, out of fear of a lecturing ;-)

Glenn.

Glenn Vassallo said:

out of fear of a lecturing ;-)

And - a "lecturing" is to be feared?  From this always kind, gentle, satellite launch-scuttling reporter - I think not...

Hi Cb1_mobile,

I have been facing problem with debugging mode in  keil. I am able to  download code but could not able to debug.

I am using Tiva C Launchpad TM4c123GXl . Would you please help me with this.

Regards,

Meet

Best advice (I can dream up) follows:

a) do not - at this early stage - attempt to create your own/custom project - instead use a short, simple project provided either by Keil or better yet - this vendor!

b) it is important that you include a proper - MCU appropriate - Start-Up file w/Keil or IAR .  (such should be included if you choose an "official" - pre-coded project.

c) have you tried - and proven - that this simple, supplied program can be downloaded successfully into your board?

d) if and when you've complied with & succeeded under "a,b,c" - again attempt debug.  Good read of the Keil operating manual is worthwhile.  If things don't seem to go right - identify with "proper/full" detail what does - and especially what does not work!   "Not able to debug" is like telling the doctor, "Doc - it hurts?"  Doc/I view you with same dumb look - "Perhaps you care to tell us where it hurts, intensity, how long, and what may have caused/contributed?...""

These are complex devices - devil is always, "in the details."

Thanks for reply cb1.

a) I am using blinky sample code which has given in Tivaware board example.

b) I haven't made any changes in example code.

c) Yes tried to download code into Launchpad its working properly.

when I press debug button in keil it goes into debug mode but after few second it comes out from debug mode. One other thing that forgot to tell  you that I have used this launchpad to program my project board.

Regards,

Meet 

Can you point me to the design document which suggests 100 Ohm current limiting resistor for VTREF ? Is this just your suggestion for safety?