TM4C123GH6PM: JTAG Lockup Issue

Hello Go,

First guess here is that it has something to do with F0 sharing NMI operation.

Since you were able to able to duplicate the problem on the LaunchPad, can you explain that piece further? Were you able to find out what code being added specifically caused the issue?

Usually the pins like F0 need to be unlocked before use, has that been done? See this post about how to do so: https://e2e.ti.com/support/microcontrollers/other/f/908/t/755561

Regarding the issue with the custom boards, I recall that sometimes the Unlock process sometimes needs to be done multiple times in order to resolve a locked board, has it been tried more than once?

Hi Ralph,
I used pinmux to add two input signals, F0 and F1. The exported pinmux.c config code includes several statements to unlock F0 before configuring that pin. F1 does not require unlocking.

It appears that the connection fails when F0 and/or F1 are first read.

We attempted to execute the the Unlock command from UniFlash many times with and without holding the target processor in reset.
I am attempting to locate and substitute an XDS100v2 for the XDS110 to retry the UniFlash Unlock tool.

Thank you for your time.
Ron

Hello Ron,

I see. That usually would make me think of a Fault ISR occurring, but that shouldn't cause the JTAG operation to be lost. I haven't really found anything that indicates PF0/1 can impact JTAG unless the PF0 is maybe not changed from NMI mode after being unlocked. Can you post the configuration code for the pins that when added caused the issue?

Also Go Bravos, if you could share with me the LaunchPad code that you have to replicate the issue, that would really help me get up to speed here so I am testing the right sequence.

Hi Ralph,

To be clear, Go Bravos originally posted this for me. I am on vacation until 7/20 at which time I can provide more information. Thank you for responding.

Ron Burati

Hello Ron,

Okay no problem, thanks for the update. If I happen to come across any ideas before then I'll let you know as well. Enjoy the time off!

Hi Ralph,

It appears that using F0 causes the JTAG connection to fail. When I add F0 as a simple input  to Pinmuc, it  generates these statements in pinmuc.c

//
// Unlock the Port Pin and Set the Commit Bit
//
HWREG(GPIO_PORTF_BASE+GPIO_O_LOCK) = GPIO_LOCK_KEY;
HWREG(GPIO_PORTF_BASE+GPIO_O_CR) |= GPIO_PIN_0;
HWREG(GPIO_PORTF_BASE+GPIO_O_LOCK) = 0x0;

//
// Configure the GPIO Pin Mux for PF0
// for T0CCP0
//
MAP_GPIOPinConfigure(GPIO_PF0_T0CCP0);
MAP_GPIOPinTypeTimer(GPIO_PORTF_BASE, GPIO_PIN_0);

Loading code built with these statements immediately causes the failure. 

(Without the addition of that input, Pinmux uses F0 for a timer signal, and there is no connection failure)

When the connection fails on the Tiva Launchpad, I can use the unlock tool in UniFlash to recover. However on our custom assembly, holding the Tiva reset low while powering up the board and running the unlock tool fails to succeed. I am using an XDS110 probe but I have also attempted the unlock using a Blackhawk USB100v2 with no success. Here is a snapshot of the board's JTAG circuit.

Knowing that there is a conflict with using F0, we can work around that, but the major issue is our inability to recover JTAG connectivity with our custom circuit board.

Thanks for your time.

Ron Burati

Hello Ron,

For what is causing the lock up itself, have you checked if the following is called beforehand:

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);

Regarding the issue with the custom board which is your bigger concern here,

Do you trigger the Unlock Sequence in Uniflash first and then follow the steps for holding Reset and powering up?

Can you scope the TDO line with the power applied and see if the line is toggling at all and at what frequency?

And lastly can you post the JTAG error you get in CCS when trying to program the bricked board? Might help me look for similar situations depending how generic vs specific it is.

Hi Ralph,

Yes, SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); is called beforehand.

The procedure for unlocking using Uniflash that we have been attempting is:

The Tiva processor is powered off

The Tiva Reset pin is jumpered low (either through a 470 ohm resistor or directly to gnd)

Power is enabled

The Uniflash Unlock command is invoked

Uniflash reports that unlocking failed

(at this point I have attempted to complete the unlock regardless of the failure message and subsequent power cycle of the processor)

The connection verify output failure in CCS is as follows:

=====================================

[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\burati\AppData\Local\TEXASI~1\CCS\
ti\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 'Feb 8 2018'.
The library build time was '18:36:28'.
The library package version is '7.0.188.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 failed.
The JTAG IR instruction scan-path is stuck-at-zero.

The test for the JTAG DR bypass path-length failed.
The JTAG DR bypass scan-path is stuck-at-zero.

-----[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.
Test 1 Word 0: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 1: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 2: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 3: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 4: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 5: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 6: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 7: scanned out 0xFFFFFFFF and scanned in 0x00000000.
The details of the first 8 errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 1, skipped: 0, failed: 1
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 1
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 2
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 3
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 4
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 5
Some of the values were corrupted - 83.3 percent.

The JTAG IR Integrity scan-test has failed.

-----[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.
Test 1 Word 0: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 1: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 2: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 3: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 4: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 5: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 6: scanned out 0xFFFFFFFF and scanned in 0x00000000.
Test 1 Word 7: scanned out 0xFFFFFFFF and scanned in 0x00000000.
The details of the first 8 errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 1, skipped: 0, failed: 1
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 1
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 2
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 3
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 4
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 5
Some of the values were corrupted - 83.3 percent.

==============================================

  --Ron

I'm using Uniflash 4.3.1.1835 from the GUI. I will try the command line.

The CCS error is

Error connecting to the target:
(Error -1170 @ 0x0)
Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).
(Emulation package 7.0.188.0)

Hi Ralph,

I think I have solved our problem.

You were right about using the tool from the command prompt. I was able to unlock the JTAG by erasing flash using command:

c:\ti\uniflash_4.3.1\deskdb\content\TICloudAgent\win\ccs_base\common\uscif>dbgjtag.exe -Y unlock,mode=tiva -f @xds100v2

Regarding the root cause of the JTAG issue, there was a conflict involving the use of F0 and F1. When they were allocated as inputs, Pinmux made other changes that seemed to effect the JTAG. I haven't yet determined exactly what those changes were but if I leave those pins allocated for timer0, nothing bad happens.

Thanks for your help. 

Ron Burati

Hi Ron,

Glad to hear that worked out for you then!

Let me know if you have any questions once you review those changes.