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 Interface: Test Connection Passes, Debug Fails Target Load With Useless Information Why, Blackhawk XDSV2 ARM

Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: MSP430FR5987, SEGGER

I cannot get a XDS100V2 to debug our custom PCAssembly.

We have a custom designed PCAssembly with the TM4C1294 controller.
The board design set the footprint for the 14 pin JTAG interface connector the same as we were using for the MSP430FR5987 JTAG interface in our product.

Pin1 TDO

Pin2 VCC TOOL

Pin3 TDI

Pin4 VCC TARGET

Pin5 TMS

Pin6 no connection

Pin7 TCK

Pin8 TEST

Pin9 GND

Pin10 no connection

Pin11 nRESET

Pin12 no connection

Pin13 no connection

Pin14 no connection

We purchased a Blackhawk XDS100V2 device programmer which has a 20 pin connector wired for ARM programing.  I wired up an adapter cable from the 20 ARM pinout to our 14 pin header.  I will post schematic for this cable later.

I opened CCS7. I had been doing development with the Launchpad and the Stellaris debug interface.  I selected the project on my computer to make it active. I opened the target_config.ccxml file
I changed the connection from the Stellaris,  to the Texas Instruments XDS100V2 USB Debug Probe and saved.
   
I set the board jumper to apply VCC Target to the JTAG interface.
Press Test Connection and got success with the following details.
[Start: Texas Instruments XDS100v2 USB Debug Probe_0]
 
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\Lee\AppData\Local\TEXASI~1\CCS\
    ccs740\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 'Nov  6 2017'.
The library build time was '10:36:36'.
The library package version is '7.0.100.0'.
The library component version is '35.35.0.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 64 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 64 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 64 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: Texas Instruments XDS100v2 USB Debug Probe_0]
Ok! Let’s Program in Debug.
I then tried to program the target by pressing the Debug.  I got an error.
Error connecting to target.  Unable to communicate with the device. Please check your connections.   
I pressed Cancel
 
   
In the console the following:  CORTEX_M4_0: Error connecting to the target: Unable to communicate with the device. Please check your connection.
 
I am at a loss for what do do next. It passed the connection test yet reports error connecting to target in debug.
  • Wiring my adapter cable.

    The error messages when I tried to program with Debug.

    I pressed cancel and got this:

  • Here is the portion of our schematic with the JTAG interface:


  • If you open your target configuration and go to the "Advanced" tab, does it look like this. (I have the TI XDS100v2 instead of the Blackhawk).

    The other concern is that JTAG is very sensitive to reflections and cross talk. Adding length to the cable often causes issues. I believe Blackhawk has 20-pin to  14-pin converters.

  • Hello Bob,
    Thanks for the screen shot. It appears my configuration is the same.

    Regarding, " I believe Blackhawk has 20-pin to 14-pin converters." Unfortunately our 14 pin connector is not wired to their standard that is why I was making the adapter cable. Regarding cross talk, I guess I would like to slow down the interface as much as possible. Any idea?

    The real issue of my post is why did my connection pass the Connection Test but then fail when I tried to program the target? What might be different in the two cases that would give me a clue to what is wrong?
  • Slowing down the JTAG clock does not help with cross talk or reflections as it is the energy in the signal edge, not the fundamental clock frequency that is the problem. Proper termination on TCK minimizes reflections. Short cables or alternating grounds will minimize cross talk.
  • I am trying to cross check the table you provided and the schematic you provided. Did you connect TRST (test reset) from the XDS100V2 to RESET of the TM$C1294? If so, disconnect them. They are different signals. TRST is not used on the TM4C1294 device.
  • Hello Bob,
    Sorry to go dark for a few days, as I was switching back to other tasks.
    Thanks for reviewing my schematic and find and suggesting the change to TRST.

    Unfortunately, no joy.

    My notes:

    I tested connecting the Black Hawk to the target with the modified cable and the "Test Connection" passes but programing the target fails with the same error as above.


    I have disconnected TRSTn pin 3 on the ARM JTAG connector and retested and get the same results. The device passes the "Test Connection" but fails to program the unit with the error "CORTEX_M4_0: Error connecting to the target: Unable to communicate with the device. Please check your connection."


    To try to learn more about how the self  "Test Connection" and programing works I made an experiment.FYI. If I disconnect the JTAG plug from our target PCAssembly the "Test Connection" reports failure like this:

    [Start: Texas Instruments XDS100v2 USB Debug Probe_0]
    
    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\Lee\AppData\Local\TEXASI~1\CCS\
        ccs740\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 'Nov  6 2017'.
    The library build time was '10:36:36'.
    The library package version is '7.0.100.0'.
    The library component version is '35.35.0.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 '-180' (0xffffff4c).
    The title is 'SC_ERR_CTL_NO_TRG_POWER'.
    
    The explanation is:
    The controller has detected a target power loss.
    The user must turn-on or connect the power supply for the target.
    
    [End: Texas Instruments XDS100v2 USB Debug Probe_0]
    

    And when i try with the connector unplugged to program in Debug mode the error dialog is:

    Error connecting to the target:
    Unable to communicate with the device. Please check your connection.

    I do not understand enough to attempt a guess for how to test further.  (Edited line.)

  • Can you check that Vcc_Target to the Blackhawk is at 3.3V and that TM4C1294 pin 70 (Reset) is 3.3V?
  • Forrest Erickson said:
    The device  passes the "Test Connection" but  fails to program the unit with the error "CORTEX_M4_0: Error connecting to the target:   Unable to communicate with the device. Please check your connection."

    You've reported this key (contrasting) finding twice now - and this conflict  (almost surely)  'begs'  explanation!       If there exists (ANY) faith in the 'Test Connection' report - then vendor's direction to 'confirm' the presence of 3V3 - proves questionable.

    Here's my suggerstion for a (proper) beginning approach toward such 'explanation?'   (Can the (Passing)  'Test Connection' report be believed?)

    • As the 'Test Connection' Passes - should not it be asked: is it as 'strict' - or as 'encompassing' - as the (more standard) 'Programming attempt?'     My group notes that (others HERE) have also received 'PASS' from this 'Connection Test' - yet just like you - their programming attempt  FAILS!
    • Proper  scope caps  (aligned & equalized)  -  properly  'Contrasting/Comparing'  key signals under 'Test Connection' and then 'Programming Attempt'  may prove insightful.    You (really) require 'hard data' - do you not?       The progression of highly 'cryptic' diagnostic codes appear of 'little' (i.e. absolutely NO Value ) - you (appear) 'Left to your own devices' to overcome such issue...  
    • I'd attempt to 'Program'  with (ONLY) the smallest, simplest - vendor supplied example program - to insure that (your) program is not 'aiding/abetting' the Program Failure.
    • I did not note (proper) external pull-up resistors @ each of your JTAG pins.     Relying upon the (far too high value) MCU pull-ups - makes little sense.
    • Vendor's Bob makes a good point about 'reflection' - the addition of 33-75Ω resistors - between JTAG header & MCU's JTAG pins - has been shown to 'raise signal robustness.'
    • To firm's/my mind - the Segger 'J-Link' proves (far) superior to the JTAG Probes offered here.   (It IS the Top Selling such probe - has LONG pre-existed those here - and is available under an 'educational discount' (which does not require your 'fabrication' of student status) which dramatically reduces cost.    In addition - use of a 'Vendor Agnostic' Tool opens your usage to the broad range of ARM MCUs - is it 'wise' to (further) lock yourself - to a device which 'resists' your programming efforts?

  • I have checked and found both to be 3.3V.

    I should explain another thing. I have no problem programing the target using the Launchpad EX=-TM4C1294XL as a programer. I removed the pin to pin jumpers on the Launch pad. I made a cable to take the JTAG signals from the Launchpad to our target custom PCAssembly.

    We intend to use a purchased of the shelf programmer for our production rather than a home brew setup with an evaluation board. That is why I am trying to get the Blackhawk working.


  • This might be a duplicate. My reply from earlier today has not appeared.

    I observed with an oscilloscope the Vcc_Target and the Reset. Both are at 3.3V and no noise.

    Further information. Using a EK-TM4C1294 launchpad I can program our customer PCAssembly hardware. The problem I am trying to solve is why the Blackhawk passes the Test Connection but fails when actually programing.
  • I have the Blackhawk programing our custom PCAssembly.  There was no problem with the adapter I wired up. The problem was configuration setup in or software project.

    I went searching for examples of setting configuration and found this tutorial:

    I used the menu View> Target Configurations and found the view for my target has two .ccxml files.

    When I selected the file I had not seen before, it still showed a Stellarius  JTAG device. So I changed to XDSV100V2 saved and tested the connection which passed. When I pressed the DEBUG to program the target I had success.

    Here is the view of the two files:

    There was a clue all along. In an earlier image of the failed to connect dialog you can see it still says Stellaris not the XDSV200V2.
    I will pose an image of  the dialog as programing is successful and you can see "XDS100V2 USB Debug Probe" in the dialog.


    I have no idea why there are two .ccxml files in our software. The person who made this project is no longer with our company.




  • There was a clue all along. In an earlier image of the failed to connect dialog you can see it still says Stellaris not the XDSV200V2.

    Here is the dialog as programing is successful and you can see "XDS100V2 USB Debug Probe" in the dialog.

    My problem (could not program with Blackhawk) is resolved. 

    Though my observation that the failure to connect dialog message from CCS7 was useless for finding the problem because it was so vague. It did not help me focus on and find the real problem.

    If there are some TI people reading this please ask the developers to offer a more helpful description of why the Loading Program failed.