Connnection problem between XDS100v2 ARM and TM4C123GH6PGE

Hello,

Could you please post more of your schematic, so that I can see the JTAG connections going to the TM4C123GH6PGE?

-David

No pull-up resistors - across each/every JTAG signal line - reveal.  We find it always "safest" to place 4K7-10K between each JTAG line & 3V3.  (while internal, weak, pull-up Rs may be resident w/in the MCU - often enough we've found these to be insufficiently robust - signal margins degraded) 

Four 06-03 smt Rs add little to your cost/size pcb budget - peace of mind may warrant that small investment...  Or, famed, knowing, gov't proclamation, "If you like your JTAG uncertainty - you can keep your JTAG uncertainty..."   We do not...

I have attached my complete board schematics.Kindly  help me as soon as possible.

And apart from the board connections, how to check whether my controller is in a working state.(This was a new controller that i have recently bought)

Thanks in advance

7725.schematics_zoom.pdf

Can anyone please help me.

Thanks in advance

@Sai

Besides the post already stating it is better to have Pull Up Resistors, there are a few things you may want to check

1. After connecting the Debugger, does the RST_N pin show 3.3V or 0V. This is to make sure it is not being driven by the XDS100V2 to GND.

2. The VDDC Pins on the uC as per the electrical specification must have an external cap of 2.2uF-4.7uF which clearly the schematics do not have.

3. Looking at the IR-DR sequence, it could be a case of a Locked Part. Did you try using the LMFlash Application to unlock the part and re-try

~Amit

Hi Amit Ashara,

Thanks for the reply.

1) I have kept pull up resistors

2) Are my JTAG connections right? (I am using XDS100V2 ARM)

3)If possible can you give schematics for JTAG

4)I have attached 2.2uf to one of the VDDC pins.(I cannot give to both on my board.But I see them shorted internally)

5)But I don't see 1.2V at VDDC pin (It's in the order of mV)

6) How do I unlock with LM Flash ?

I am still getting the same errors

Thanks in advance

@Sai

If the VDDC is not ~1.2V, then most probably your device is not well powered. Can you please check both VDDS and VDDA Supplies to be 3.3V.

Also I am not sure about the #1 you stated. Which Pull Up Resistor are you referring to.

#2. Do not connect the XDS100V2 and then check if VDDS=VDDA=3.3V

At this point don't connect the debugger and let's get back to ELEC101

Amit

Hi Amit Ashara,

A small mistake I made was not connecting AVDD to 3.3V. As soon as I connected AVDD to 3.3V ,controller's core voltage(VDDC) gave 1.2V. Thanks for the comment made.I can conform that controller works.

I have removed pull up resistors for all JTAG signals (it was suggested in "System Design Guidelines for Tiva™ C Series Micro controllers").

After this I ran "Test connection" . The result was

[Start]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

[Result]

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

C:\Users\WOLVER~1\AppData\Local\.TI\693494126\
0\0\BrdDat\testBoard.dat

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

This utility has selected a 100- or 510-class product.
This utility will load the adapter 'jioserdesusb.dll'.
The library build date was 'Aug 20 2013'.
The library build time was '22:56:19'.
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.
The controller has a version number of '4' (0x00000004).
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]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[The log-file for the JTAG TCLK output generated from the PLL]----------

There is no hardware for programming the JTAG TCLK frequency.

-----[Measure the source and frequency of the final JTAG TCLKR input]--------

There is no hardware for measuring the JTAG TCLK frequency.

-----[Perform the standard path-length test on the JTAG IR and DR]-----------

This path-length test uses blocks of 512 32-bit words.

The test for the JTAG IR instruction path-length succeeded.
The JTAG IR instruction path-length is 4 bits.

The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 1 bits.

-----[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]

So, it says JTAG integrity scan was success(but no hardware for programming the JTAG TCLK frequency.)

 When I try to debug the code i get the following error:

CORTEX_M4_0: Error connecting to the target: (Error -1063 @ 0x0) Device ID is not recognized or is not supported by driver. Confirm device and emulator configuration is correct, or update device driver. (Emulation package 5.1.232.0)

What does it mean? How should I overcome this error? 

I have read some forums. Some of them say to clean cache,delete launch config file. I did all those in my CCS. Even then it gives me the same error. 

I feel this might be a problem with T_RST/nReset. (I am not sure).Can you please verify my JTAG connections which I have attached before. My controller doesn't  have a TRST pin. nReset pin is connected to the controller reset pin.This pin is pulled up by a resistor and is connected to a tactile switch. I have verified the voltage to reset pin to be 3.3V. TRST pin from the debugger is pulled up by a resistor.

I have even tried connecting TRST pin to controller reset pin (both pull up / pull down configurations). Same error prevails.

Can some one please help me in this.

Thanks in advance

@Sai

Glad to hear the core is now up

If the RST_N pin is showing 3.3V then reset is not the problem here. You may want to check E2E forum for CCS for any such issues.

Amit

Reset pin of the controller is showing 3.3V.

So, you are saying it is a problem with CCS?

I worry whether my JTAG connections are right. T_RST(test reset) from the debugger is no where connected to the controller. Is this right? I have read many forums and documents. They confuse me between TRST and SRST.

Can anyone please help me in this issue. I have seen many forums with the same problem.But nowhere I find a solution to rectify my problem. It would be really a great help if someone helps .

Thanks in advance 

@Sai

I tried the same on my side and it works fine. I am able to connect to my TIVA Part with a Olimex TMS320-JTAG-USB-XDS100-V2. The difference this has w.r.t to the Blackhawk is that Blackhawk has a 20-pin ARM connector while Olimex has cJTAG TI 20-pin connector, causing me to wire up my board.

So I looked into your post a second time. I am not sure which version of BlackHawk XDS100V2 are using. Can you send me the model number. Also a little search into the BlackHawk shows that there are two types of XDS100V2 Debuggers

http://www.blackhawk-dsp.com/products/USB100v2ARM.aspx

http://www.blackhawk-dsp.com/products/USB100v2D.aspx

The second does not support Cortex M core. I hope you did not order the second one, which may be the root of the problem

Amit

Hi Amit  Ashara,

I am using XDS100V2 ARM. 20 pin connector.

I am still unable to figure out the problem. :(

Hope you find a solution for this problem.

Thank you

@Sai,

Can you send the ccxml file. I can try using the same and see if my board still connects. Other than that some standard things that you may want to try

1. Remove the configuration file ccxml and start a fresh project. Do not copy anything but your code.

2. Remove CCSV5 from your system and re-install fresh

3. Open a thread with CCS E2E forum on the same

Amit

Hi Amit Ashara,

Thanks for such a quick reply. This is my ccxml file:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
<configuration XML_version="1.2" id="configuration_0">
<instance XML_version="1.2" desc="Texas Instruments XDS100v2 USB Emulator" href="connections/TIXDS100v2_Connection.xml" id="Texas Instruments XDS100v2 USB Emulator" xml="TIXDS100v2_Connection.xml" xmlpath="connections"/>
<connection XML_version="1.2" id="Texas Instruments XDS100v2 USB Emulator">
<instance XML_version="1.2" href="drivers/tixds100v2cs_dap.xml" id="drivers" xml="tixds100v2cs_dap.xml" xmlpath="drivers"/>
<instance XML_version="1.2" href="drivers/5340.tixds100v2cortexM.xml" id="drivers" xml="5340.tixds100v2cortexM.xml" xmlpath="drivers"/>
<property Type="choicelist" Value="3" id="The JTAG TCLK Frequency (MHz)"/>
<platform XML_version="1.2" id="platform_0">
<instance XML_version="1.2" desc="Tiva TM4C123GH6PGE" href="devices/tm4c123gh6pge.xml" id="Tiva TM4C123GH6PGE" xml="tm4c123gh6pge.xml" xmlpath="devices"/>
</platform>
</connection>
</configuration>
</configurations>

Thank You

@Sai

The ccxml file is way different from what I have. Below is my ccxml file that allowed me to connect. I am not able to load your ccxml file in CCSV5 for some reason (I haven't figured out yet). You can try using the following file

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
<configuration XML_version="1.2" id="configuration_0">
<instance XML_version="1.2" desc="Texas Instruments XDS100v2 USB Emulator" href="connections/TIXDS100v2_Connection.xml" id="Texas Instruments XDS100v2 USB Emulator" xml="TIXDS100v2_Connection.xml" xmlpath="connections"/>
<connection XML_version="1.2" id="Texas Instruments XDS100v2 USB Emulator">
<instance XML_version="1.2" href="drivers/tixds100v2cs_dap.xml" id="drivers" xml="tixds100v2cs_dap.xml" xmlpath="drivers"/>
<instance XML_version="1.2" href="drivers/5340.tixds100v2cortexM.xml" id="drivers" xml="5340.tixds100v2cortexM.xml" xmlpath="drivers"/>
<property Type="choicelist" Value="3" id="The JTAG TCLK Frequency (MHz)"/>
<platform XML_version="1.2" id="platform_0">
<instance XML_version="1.2" desc="Tiva TM4C123GH6PGE" href="devices/tm4c123gh6pge.xml" id="Tiva TM4C123GH6PGE" xml="tm4c123gh6pge.xml" xmlpath="devices"/>
</platform>
</connection>
</configuration>
</configurations>

Amit

@Sai

Attaching the corrected file that gets loaded. Rename it as ccxml

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
    





<configuration XML_version="1.2" id="Texas Instruments XDS100v2 USB Emulator_0">
        <instance XML_version="1.2" desc="Texas Instruments XDS100v2 USB Emulator_0" href="connections/TIXDS100v2_Connection.xml" id="Texas Instruments XDS100v2 USB Emulator_0" xml="TIXDS100v2_Connection.xml" xmlpath="connections"/>
        <connection XML_version="1.2" id="Texas Instruments XDS100v2 USB Emulator_0">
            <instance XML_version="1.2" href="drivers/tixds100v2cs_dap.xml" id="drivers" xml="tixds100v2cs_dap.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds100v2cortexM.xml" id="drivers" xml="tixds100v2cortexM.xml" xmlpath="drivers"/>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="Tiva TM4C123GH6PGE_0" href="devices/tm4c123gh6pge.xml" id="Tiva TM4C123GH6PGE_0" xml="tm4c123gh6pge.xml" xmlpath="devices"/>
            </platform>
        </connection>
    </configuration>
</configurations>

Amit

Hi Amit Ashara

Your ccxml file is same as mine. Is this working for you. If yes, what are the JTAG connections you made?

I have reinstalled CCS5. Created a new project. Even then this error prevails.I feel this problem is not with  CCS

I even posted in BlackHawk online support.  After seeing my 'test connection' log file, they said:

@Sai

I realized the mistake and attached the ccxml file as txt file. Do not refer the ccxml file content I pasted in the post, but the file attached in my later post.

When you created a new project did you import the previous ccxml file or did you create a new one?

The GEL files are predefined for different devices. I will look into it as well, but I am not an expert at GEL files. The problem I see is that XDS100V2 worked fine for me and since I cannot reproduce the problem, it is rather tough to say. I am seeing if I can get a BlackHawk Debugger

Amit

Hello Amit,

I just wanted to update your earlier comment and let you know that both Blackhawk XDS100v2 models support every device the TI XDS100v2 reference design supports.  The only difference is the JTAG target connection.  One is designed for cTI JTAG headers and the other is designed for ARM JTAG connections.

With respect to this customer's issue. We have determined that the CCS test connection runs without error, so the emulator hardware is installed correctly and functioning properly.  We could not duplicate the Device ID error.

In the last "test connection" output posted, the information is not the same as shown earlier.  It now has errors.  Our best guess is that the device is not in a state to allow emulation debug.

 - Andrew

Hello Andrew,

The last test connection I posted was :

Start]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

[Result]

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

C:\Users\WOLVER~1\AppData\Local\.TI\693494126\
0\0\BrdDat\testBoard.dat

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

This utility has selected a 100- or 510-class product.
This utility will load the adapter 'jioserdesusb.dll'.
The library build date was 'Aug 20 2013'.
The library build time was '22:56:19'.
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.
The controller has a version number of '4' (0x00000004).
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]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[The log-file for the JTAG TCLK output generated from the PLL]----------

There is no hardware for programming the JTAG TCLK frequency.

-----[Measure the source and frequency of the final JTAG TCLKR input]--------

There is no hardware for measuring the JTAG TCLK frequency.

-----[Perform the standard path-length test on the JTAG IR and DR]-----------

This path-length test uses blocks of 512 32-bit words.

The test for the JTAG IR instruction path-length succeeded.
The JTAG IR instruction path-length is 4 bits.

The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 1 bits.

-----[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]

I have posted this on Dec25. I do not know why I cannot see this in the above forum.

But anyways, the test connection says JTAG integrity scan-test succeeded. After seeing this log file, Black Hawk support says there is no problem with the emulator .

Thank You

Hi Amit,

This is how I always create a project. I will import "hello" program from 'tm4c123gxl' folder in tivaware.

Then I change the device properties, connection type and changes in the source file,startup_ccs.

I created a new project (in the similar way as I mentioned above). I have added your target_config.ccxml file(the recent one you have attached). Then I made it as "active" configuration.

Then I tried test connection. It gives me the same results as before(JTAG integrity test succeed)

But unfortunately when I debug, I get the same error again.(Device ID not found)

Thank you.

@Sai,

We need to debug the HW as Emulator does seem to be fine. I would ask you to send me the following data

1. Connect Pull Up on the TDO Line, power the board (do not connect the debugger) and see the state of the TDO Line on a scope. When connecting a Pull Up please use 3 different values of 1K, 10K and 100K. The plots for the 3 are important here.

Based on the above data, we can determine if the device is in a State to enter debug mode or not

Amit

Hi Amit,

Extremely sorry for the late reply.

After powering the board(without debugger attached), TDI,TMS,TDO,TCK pins are 'high'. 

"System guidelines for Tiva C series " document also says that all these pins have internal pullup resistors by default. No external pull up resistors are required. 

But as you said I even connected external pull up resistors of 1K,10K and 100k for TDO ( I did not connect pull ups for other signals.)I have attached the pics below.

I have even attached TDI and TDO signals (with no external pull ups attached) while performing 'Test connection" in CCS.

Kindly go through the attachments.

Thank You

1263.Pics.rar

Hi Sai,

Thanks for the waveforms The device looks fine as well from the waveforms. I will be checking the same with a BlackHawk Debugger some time next week, but it looks unlikely either based on previous thread that it or CCS could be the problem here.

In the meantime if you can send/attach the project setup as a zip file, I can load it on my DK board with CCS and see if there is something else. Basically I want to rule out as many unknowns as possible

Amit

Hi Sai

I used a BlackHawk XDS100V2-ARM debugger with CCSv5 and it also connected to the board without any issues. I am still looking forward for the project files from you to be imported in my setup.

Amit

Hi Amit,

I have attached my project folder.

If your board is working with XDS100V2 ARM, can you send the schematics/board files of it. It would be of great help.

4744.TIVA.rar 

Hi Sai

Your project filed compiled and loaded in my setup without any issues. I am using a custom board derived from the EK-TM4C123. I will review your schematic v/s mine and can point out some of the differences.

Did you try replacing the TM4C123 part on your board if you have a couple of them on standby.

Amit

Hi Amit,

1) Can you please send your schematic files. Even I will verify with that.

2) I have only one more spare controller. I want to replace the controller only if there is a proper reason that the present one is spoiled

Thank You

@Sai,

Having only one spare controller, would indeed be jeopardizing your progress in the short term. But considering that we are getting nowhere it is a reasonable risk.

I had some luck today in reproducing your problem. I have a locked part which showed the same behavior as you last message. The JTAG Integrity test passed w/o any issues. But when I tried to connect the debugger it gave the same Error as yours.

Unlocking a part can be done through the LMFlashProgrammer, but you would be needing a Stellaris ICDI board to do so. It cannot be done with XDS100V2. I did check CCS forum and they do not implement Unlocking Sequence (you may want to double check as well before loading the new part).

Now why a part may have got locked, there could be multiple reasons, but the considering that there were power supply problems in the beginning, it could have had damage the uC. You may have to send the locked part back to TI for RMA so that we can ascertain why the part is in such a state.

Amit

Hi Amit,

Can you send your board schematics files.I want to verify mine before replacing the controller.

Thank You

Hi Sai,

Unfortunately, the schematics of my board are TI Internal Documents and cannot be published. But from the XDS100V2-ARM 20 Pin Header, I have changed it to match exactly yours including the connections and the resistances that have been used.

Amit

Has not Amit's long, oft-repeated attempts to resolve/satisfy, yet registered as sufficient?

Do not better/stronger lessons reveal from this saga?

a) Is it wise to, "save" < 15USD and, "build your own board?"

b) Is it wise to misconnect/misroute potentially critical power pins - and then properly investigate/discover, "after the fact?"

c) Is not some other board available so that your project (earlier announced as, "due" Dec end) may continue?

Broadening your scope/horizons often helps - borrowing a friend's (working) board, or one from school, or co-worker may link your issue to your board, JTAG probe, or IDE.  Building a board from scratch, errant MCU power connections, and (apparent) first use of JTAG probe tend to maximize your sources of error - do they not? 

Eval boards, launch boards exist as, "safeguards" against the very issues you report.  (and report & report...)   Further beating of this (already dead) horse may not speed you along your journey...

@cb1_mobile,

Thanks for your suggestions.

I already did my project on launch boards(it includes more than two  boards). My final end of the project is to make a customized working board. This was the first time I am making a board for this controller. I couldn't find anyone who worked/made a board for this controller(or stellaris variant) in my circle.

My mistake was to start this part at a very later stage.

Thank you.

Hi Sai,

Did the part replacement resolve the issue?

Amit

Hi Amit,

I have replaced the controller as you said. 

Error:

CORTEX_M4_0: Trouble Setting Breakpoint with the Action "Terminate Program Execution" at 0xd18: (Error -1066 @ 0xD18) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 5.1.232.0)
CORTEX_M4_0: Trouble Setting Breakpoint with the Action "Finish Auto Run" at 0x458: (Error -1066 @ 0x458) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 5.1.232.0)

Can't find a source file at "/tmp/TI_MKLIBBMPOk8/SRC/auto_init.asm"
Locate the file or edit the source lookup path to include its location.

I got the same error when I debugged first time to the previous controller.After that, it was giving "Device ID not found". Even now, for the first time it actually burns the code and waits for the play button to be pressed.But when you hit the play button, you get this error(as stated above) at the bottom. And from the next time, it just says "Device ID not found".

Do you have any idea of this kind of problem?

Thanks in advance.

Hi Sai,

Now that is the information that was required. For some reason your test code is causing the device to lock up. Usual suspects will be

1. The test may have configured the JTAG Pins to GPIO or some other functions and since it is Flashed, every time you power it up, the code executes and JTAG is lost

2. The test may have incorrectly locked the device at a frequency from which it cannot recover. Either the frequency is too low or too high (violating the max frequency)

Unfortunately you need to run the Unlocking sequence using LMFlashProgrammer which requires a Stellaris ICDI board at least. You can get a ICDI board along with a EK-LM3S kits, and wire it up to your exisiting board.

It would be good to post the code you are running if you are not able to figure out why the part is locking

Amit

Hi Amit,

I am very happy that the problem was found.Even I felt similar to this, when it happened for the new controller.

But,

1) Datasheet says that JTAG pins come under PORT_C. I did not use any pin related to PORT_C.

2) I did not understand your second point.(Note: I did not connect external crystal on the board. Will this be a problem? Controller can anyway generate it  right ?)

3) How to run unlocking sequence using LMFlash programmer? I have Tiva Launch pad. Will that help?

I am attaching my project folder.Kindly go through my code. Please do suggest some corrections if any.

0743.TIVA.rar

Thank You

Hi Sai,

1. You are correct, that JTAG comes under PORT_C and your code does not use it so definitely we can rule this one out

2. The code is configuring the clock from the external crystal. The function does take care to check if the MOSC is powered up. This is the interesting part as it seems to detect a crystal when there is none. I would strongly suggest to mount the external crystal and then see if you are able to connect via CCS. Not having a crystal and leaving it unconnected can be serious problem, if it injects noise making the clock detection circuit believe a valid crystal is present.

I have to check the launch pad to see if there is some method to bypass and blue-wire it to your board. This would take some time as I have to try the same and confirm.

Again strongly recommend to mount the crystal and then check.

Amit

Hi Sai,

You can use the Tiva LaunchPad as a debugger, but you will need to make some custom connections.

Please follow the instructions here: http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To

-David

Hi Amit ,

I have soldered 16MHz crystal on my board as you said. It worked for a moment. I was very happy to see it working.

But later , it caused me problems again. I again have this power issue. For a strange reason, resistance between VDD and GND went down to 30 ohms immediately after the power is switched off. And if i recheck it after few minutes it comes back to 270Kohms. Even VDDC is not generated(supply to AVDD is given). Controller doesn't get heated.

But any ways, problem with the crystal has been solved. I need to figure out power issues.Kindly help me if you are familiar with these kind of situation.

Thanks a lot.

Sai,

Glad to hear that you are almost there and the missing crystal was the cause. You should check the Table for "Connection for Unused Signals", especially when such details about the board are not visible to others. This would have gone a long way.

On the second issue, If the device is coming back up after sometime, then definitely the device is not the cause. If the resistance between VDD and GND is 30ohms, then the device would be starved of current to power up and hence no VDDC (that is expected). You may want to look under what conditions does it fail like this. May be some external device on your board (that I may not be aware of), which switches ON during code execution

Amit

Hi amit,

Though I have MSP430 on the board, it is switched off. It has completely different path for power supply.There is no way that it interfaces with Tiva controller except for some communication interfaces and common GND.

The above thing that I have mentioned was just the controller + led(power) given with 3.3 V from a standard power supply  but with a current limit upto ~200mA. I can see  current on the display. It takes around 100mA. I have measured LED current to be 4mA.

Other thing I have noticed is whenever I connect debug emulator, resistance between VDD and GND goes down to ~30Kohms. 

1)Will emulator consumes current from the board? 

2) Should I increase the current limit in the power supply?(I restricted the current to be 200mA so as to make sure that controller does not burn)

3)Do you have any other suggestions?

Thank you.

Hi Sai,

200mA current limit is fine. The BH-XDS does not source current from the Vsupply or the Vref. You can read more about it

http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide

You can try increasing the current limit or after Flashing code remove the XDS cable and then use the RST switch to start your code. What is still not clear is as to when during the entire process of code execution or some step you perform does it happen. That is something you need to first find out if increasing the current limit does not help.

Amit

Hi Amit Ashara,

I am using a TMS320-XDS100-V2 jtag programmer from olimex for programming the TM4C1237H6PZ  controllers.

I would like to know whether the 20 pin connector provided with XDS100-V2 comes with the standard JTAG 20 PIN connection. Also I would like to know how to program it using the CCS v5 since in one of the TI article I read that you have used the same device.

Regards

Dhanush 

Hello Dhanush,

The type of header on the Olimex XDS100V2 should be mentioned in the Datasheet. If it is a standard ARM 20-pin connector then it will mate well with your board. In CCSv5 you need to select XDS100V2 for Target Configuration.

Regards

Amit