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.

TMS320F28054M: Uniflash JTAG programming issue - Error connecting to the target: (Error -1135 @ 0x0) - low VDD pin voltage

Part Number: TMS320F28054M
Other Parts Discussed in Thread: DRV8312, UNIFLASH, TMDSEMU110-U

Tool/software:

Hello, 

I've inherited a project from a previous engineer. We have a custom circuit board with three (X, Y and Z) TMS320F28054M microcontrollers (80-pin LQFP), each controlling their own DRV8312 motor drivers. 

The problem is that I only get the error "Error connecting to the target: (Error -1135 @ 0x0)" whenever I attempt to program through the JTAG pins the "Z" F28054M microcontroller using a "Texas Instruments XDS100v2 USB Debug Probe" through UniFlash (version 9.1) on the bench, with no motors connected to the board - but not the X or Y microcontrollers.

I can program the other two (X and Y) F28054M microcontrollers just fine. I can even program the Z microcontroller once every 100 attempts. But mostly, I get the following errors:

Error connecting to the target: (Error -1135 @ 0x3FF77B) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 20.1.0.3372)

Or more rarely:

Error connecting to the target: (Error -1015 @ 0x0) Device is not responding to the request. Device may be locked, or the debug probe connection may be unreliable. Unlock the device if possible (e.g. use wait in reset mode, and power-cycle the board). If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.1.0.3372)

Or more rarely:

Trouble Halting Target CPU: (Error -1156 @ 0x0) Device may be operating in low-power mode. Do you want to bring it out of this mode? Choose 'Yes' to force the device to wake up and retry the operation. Choose 'No' to retry the operation without waking the device. (Emulation package 20.1.0.3372)

I do notice that the VDD pins (6, 54, 73) are 1.895V to 1.908V on the "bad" Z microcontroller, whereas the X & Y "good" microcontrollers that do program successfully have their VDD pins at 1.910V to 1.920V. Otherwise their connections are identical to one another. The VDD pins are connected to 2.2uF. We are using the on-chip voltage regulator (VREG) to generate VDD by tying "VREGENZ" pin 71 to ground. The VDDIO pins (70, 38) are at 3.924V to 3.926V for all three microcontrollers. 

More background: These are fresh production circuit boards whose design has not changed for over 2 years. The Z microcontroller is the only one that causes these errors on over 5 boards. I've also tried programming the same firmware on all three microocontrollers, yet the Z axis microcontroller continues to cause the "Error -1015 @ 0x0" as if my programmer isn't connected to anything at all. 

Next Steps: I'll try to debug through Code Composer. Then I'm going to try to use a TMDSEMU110-U debug probe next to program the Z microcontroller through Uniflash to see if there's any success. Then I'll try to swap an X or Y microcontroller in the place for the Z microcontroller to see of the microcontroller itself is bad (unlikely if the error is on this specific microcontroller on the same position on multiple boards).  

My questions: is there any direction I should focus on while debugging this issue? Is it a power issue, perhaps the Z microcontroller's output pins are driving too much current? Or is it a programmer issue? How can I increase the voltage on the VDD pins, and what factors could decrease their voltage? Is 1.910V some special threshold for the flash memory to function or something? I've also read the threads on:

Debugging JTAG

  • Hello,

    The VDDIO pins (70, 38) are at 3.924V to 3.926V for all three microcontrollers. 

    The device is operating with VDDIO outside of the "Recommended Operating Conditions", but within the "Absolute Maximum Ratings". TI recommends 3.63 V as the max VDDIO. This means that the datasheet specifications are not guaranteed. In other words, functional operation of the device at these or any other conditions beyond those indicated under the Recommended Operating Conditions is not implied. Exposure to absolute-maximum-rated conditions for extended periods may affect device reliability.

    From the datasheet:

    Best,

    Matt

  • Hi Matt, thank you for the prompt reply, I actually mistyped, the VDDIO pins are actually 3.294V to 3.296V, sorry about that. I just measured another board, those VDDIO pins are at 3.301V. 

    Another clue this morning was when my colleague used his another Texas Instruments XDS100v2 USB Debug Probe on the exact same board and same "Z" F28054M microcontroller, and he got the error:

    [5/27/2025, 7:03:07 AM] [ERROR] C28xx: Trouble Halting Target CPU: (Error -1138 @ 0x6) Device refused to allow debug mode. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00042)

    [5/27/2025, 7:03:07 AM] [ERROR] C28xx: Error: (Error -1135 @ 0x0) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.3.0.00042)

    [5/27/2025, 7:03:07 AM] [ERROR] C28xx: Unable to determine target status after 20 attempts

    [5/27/2025, 7:03:07 AM] [ERROR] C28xx: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

    BUT, once he disconnected and reconnected the USB cable from the debugger, he got:

    [5/27/2025, 7:11:51 AM] [SUCCESS] Program Load completed successfully.

    And this happens repeatedly, first the error, then cycling the USB connection, then successful programming. 

    This points to my XDS100v2 USB Debug Probe being faulty. Is there a known issue on this probe that requires power cycling it?

     

  • Hello,

    I actually mistyped, the VDDIO pins are actually 3.294V to 3.296V, sorry about that. I just measured another board, those VDDIO pins are at 3.301V. 

    Perfect, thank you for confirming the device is operating within spec.

    And this happens repeatedly, first the error, then cycling the USB connection, then successful programming. 

    Does this happen when using a different debugger? Can you try using a different USB with the debugger?

    If it's not an isolated issue, please refer to these threads for potential root causes:

    Best,

    Matt

  • Sure, I'm going to try the XDS110 Debugger soon and let you know the results. I've already changed the USB cable to a recently purchased USBA-USBmini. BTW, when I run the "Test Connection" on CCS v12.8, I get the following:

    [Start: Texas Instruments XDS100v2 USB Emulator_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\saad.k\AppData\Local\TEXASI~1\CCS\
    ccs1281\0\0\BrdDat\testBoard.dat

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

    This utility has selected a 100/110/510 class product.
    This utility will load the adapter 'jioserdesusb.dll'.
    The library build date was 'Sep 26 2024'.
    The library build time was '10:09:41'.
    The library package version is '20.0.0.3178'.
    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 38 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 Emulator_0]

  • Fascinating, the above "Test Connection" report was for a functioning "X" F28054M microcontroller, which then programmed correctly (it was failing to program with my XDS100v2 debugger this morning. I thought that perhaps the "Test Connection" button in the CCS .ccxml window somehow corrected whatever corruption was happening in the XDS100v2 debug probe. So I moved the debug probe to the troublesome "Z" F28054M microcontroller, pressed the "Test Connection" button, and got the following failures:

    [Start: Texas Instruments XDS100v2 USB Emulator_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\saad.k\AppData\Local\TEXASI~1\CCS\
    ccs1281\0\0\BrdDat\testBoard.dat

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

    This utility has selected a 100/110/510 class product.
    This utility will load the adapter 'jioserdesusb.dll'.
    The library build date was 'Sep 26 2024'.
    The library build time was '10:09:41'.
    The library package version is '20.0.0.3178'.
    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-ones.

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

    -----[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.
    Test 2 Word 0: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 1: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 2: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 3: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 4: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 5: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 6: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 7: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    The details of the first 8 errors have been provided.
    The utility will now report only the count of failed tests.
    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.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Test 2 Word 0: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 1: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 2: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 3: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 4: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 5: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 6: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    Test 2 Word 7: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
    The details of the first 8 errors have been provided.
    The utility will now report only the count of failed tests.
    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 DR Integrity scan-test has failed.

    [End: Texas Instruments XDS100v2 USB Emulator_0]

  • Hi,

    Please let me know the results with the XDS110 once you have them.

    Can you also scope the JTAG signals for the "X" and "Z" devices and compare the signals during a Test Connection? It seems like there's some noise causing interference with the JTAG connections.

    Best,

    Matt

  • Hi Matt, great news! Switching over to the XDS110 resolved the issue completely! I can program "Z" F28055, F28054M, F28054F microcontrollers just fine through JTAG. I think the issue was our very old XDS100v2 debuggers have degraded overtime and use. Still not sure why the "Z" F28054M microcontrollers caused the symptoms to show...but I'll investigate that when I really have nothing else to do lol. Thanks again Matt for your attention and valuable help and direction!