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.

JTAG error, "A bad controller handle has been given to a function..."

Other Parts Discussed in Thread: UNIFLASH, TM4C1294NCPDT, LMFLASHPROGRAMMER

HI,

I'm working on a university school project and am very new to PCB design. We've began to create a custom PCB and are attempting to debug the custom board with an XDS100v2 emulator. From what we can tell we have our pinouts correct. There are 10k pullups on the TDI and TDO lines. When we first began debugging the controller with the JTAG we did get it to download and break on main. However after we stopped the debug session (we didn't step at all in CCS) we can no longer establish the JTAG connection.

We always get the following error no matter how we connect including in UNIFLASH.

"Error connecting to the target:

(Error -121 @0x0)

A bad controller has been given to a function, either before attempting to open the controller, or after having opened the controller and ignored its error status. Valid controller handles are generated when attempts to open the controller return a clean error status. (Emulation package 5.1.507.0)"

I'm worried that the first line of code in our test program may have cause the controller to switch to a crystal configuration that doesn't work. The first line of the program is:

SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480), 120000000);

Is there any way I can erase the program externally and maybe get back to the state of a blank controller where we could debug in the first place?

Any insight will be helpful here.

Thanks!

  • Hello Justin,

    Which TM4C device is it? If it is a 123 then the clock configuration function is wrong. if it is a 129 and the crystal is less than 25MHz then the problem is that the VCO is out of bounds causing the device to crash. Please confirm.

    Regards
    Amit
  • The device is a TM4C1294NCPDT, however I'm not really sure what the VCO setting is doing to the device. I copied this code from an example and it was necessary to have these clock settings to have the ADC produce correct results on the TM4C connected Launch Pad.
  • Hello Justin

    What is the crystal frequency on the custom board?

    Regards
    Amit
  • Also, the main crystal connected is a NX3225GA-25.000M-STD-CRG-2 (25Mhz), which we tried to match up to the Launch Pad's crystal. However due to a PCB printing error we had to externally wire the controller to our PCB resulting in the crystal being a relatively far distance away from the controller.

  • Hello Justin,

    I am almost sure that the wiring of the crystal is the cause. However to get around the immediate issue, you would have to connect a LaunchPad's JTAG to the custom board JTAG to run the unlock sequence. If it is TM4c129 LaunchPad, then remove the resistors for JTAG and instead use the headers to bypass the JTAG to the custom board along with the LMFlashProgrammer.

    Attached picture will show how. Please do connect the GND of the LaunchPad to the custom board.

    Regards

    Amit

  • OK we are going to remove resistors R6, R7, R8, R10, R11, R15 and R16 as well as R40 to turn the ICDI into an outbound JTAG interface correct? And we will be able to restore the ICDI to debugging the launch pad by restoring jumpers across the terminals in X1, just to confirm.

    Will the unlock feature erase the existing program on the controller and restore it to an empty state? I thought the unlock feature of LMProgrammer would only restore the original state of the JTAG pins if they were reassigned..
  • Hello Justin,

    Yes, that is correct. It will erase everything including EEPROM, user committed registers and flash.

    Regards
    Amit
  • I've completed the removing of the resistors, and I have connected pin1->pin1 (in order to do that the red wire on the ribbon starts on our connectors VDD, then goes across the length of the launch pad and connects to U6 on the launch pad) the configuration looks awkward but electrically it makes sense.

    I've setup LMprogrammer to the TM4C1294XL Launchpad Quick Set on the first tab, then pressed unlock under Debug Port Unlock.
    It gives a warning about register erase, then prompts to assert and hold reset, then release reset, then power cycle the board, all of which I followed the directions. I then went to Flash Utilities and pressed "Erase" on the Erase Entire Flash option and receive the error message "**ERROR** Unable to initialize the target - 0!"
  • Hello Justin,

    Do not take it from U6 but from the newly installed headers which I have shown on the previous image and marked,

    Regards
    Amit
  • Hi Amit,
    We have attempted to connect those pins to the custom board as indicated but our results didn't change. We have sent our board for reprint and, since that has been submitted, any errors in JTAG can no longer be corrected. We will hope and pray that our JTAG circuit is setup correctly and that shortening the distance between the crystal and the controller resolves the problem. If we have the same problem I will proceed to post on this thread, but it won't be until Friday or next week, fingers crossed :) Thank you for all your help.

    I am curious about two things however, 1) why isn't X1 normally populated on the launch pad with connectors? and 2) why isn't the U6 connector used for outbound JTAG connections instead of the leads on X1?
  • Hello Justin,

    The primary aim of the board is to develop-debug TM4C129. Hence all connections are made so that the device is accessible w/o requiring to make changes. The U6 is primarily meant for external inbound debug.

    Regards
    Amit