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.

LAUNCHXL-F280049C: Issues after transition from LauchPad to XDS100V2

Part Number: LAUNCHXL-F280049C
Other Parts Discussed in Thread: TMS320F280041C

In Code Composer Studio (v11.1), I moved from the Launchpad (TI LAUNCHXL-F280049C) to the application hardware using an XDS100V2 USD Debug Probe.  I went into the target configuration .ccxml and selected the XDS100V2 and the target device (which is the TMS320F280041C).  I successfully test the connection using the XDS100V2.  I can run code and set breakpoints, inspect parameters, etc.  But when I make code changes, build, load, and start debugging again, I am running into JTAG errors.  I have seen error code 150 and  error -1044.  With these errors, I have to power down my whole system and start over in order to debug again.  Is there is anything else I need to do to transition from the LauchPad to an XDS100V2?.  For example, I see IcePick_C_0 in the Advanced Target Configuration and I see GEL Output statements during download. 

Please help me eliminate these errors.

  • Hi Mark,

    When you start encountering errors, you need to power-on reset before you can connect to the device again? What do you see if you test connection in this state?

    Best Regards,

    Ben Collier

  • "Test Connection" succeeded (see action #5 below). 

    Why am I getting the errors in Actions #4 and #7 below?  How do I fix these?

    • Action #1 - Initial Power On. Load – Works
    • Action #2 - Code change, rebuild, load – Works

    CONSOLE

    C28xx_CPU1: GEL Output:

    Memory Map Initialization Complete

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    • Action #3 - Press CPU Reset Icon, Press Restart Icon – Works
    • Action #4 - Debug Run – ERROR (as follows)

    CONSOLE

    C28xx_CPU1: GEL Output:

    Memory Map Initialization Complete

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: Error: (Error -1135 @ 0x874E3) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.6.0.00172)

    C28xx_CPU1: Trouble Halting Target CPU: (Error -2062 @ 0x0) Unable to halt device. 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 9.6.0.00172)

    C28xx_CPU1: Power Failure on Target CPU

     

    • Action #5 - “Test Connection” – Succeeded (as follows)

    [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\MARK~1.STA\AppData\Local\TEXASI~1\

        CCS\ccs1110\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 'Dec  8 2021'.

    The library build time was '11:16:32'.

    The library package version is '9.6.0.00172'.

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

     

    • Action #6 - Right Mouse Button Click on “Connect Target”
    • Action #7 - CPU Reset, Restart, Debug Run – STILL ERROR

    C28xx_CPU1: GEL Output:

    Memory Map Initialization Complete

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: Error: (Error -1135 @ 0x874E3) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.6.0.00172)

    C28xx_CPU1: Trouble Halting Target CPU: (Error -2062 @ 0x0) Unable to halt device. 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 9.6.0.00172)

    C28xx_CPU1: Power Failure on Target CPU

    C28xx_CPU1: GEL Output:

    Memory Map Initialization Complete

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ...

    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...

    C28xx_CPU1: JTAG Communication Error: (Error -1044 @ 0x0) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.6.0.00172)

    C28xx_CPU1: 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

     

    • Action #8 - Repeat “CPU Reset, Restart, Debug Run”, sometimes several times – Eventually works without having to do a power reset.
  • Hi Mark,

    Please give me a day to ask if anyone else has seen this issue.

    Best Regards,

    Ben Collier

  • Mark,

    Are you able to share the schematic for your board? I am particularly interested in the circuit that you have on the reset pin. Also, can you please take an oscilloscope capture of your VDDIO, VDD, XRS, and XCLKOUT signals on power up?

    Best Regards,

    Ben Collier

  • Here are the portions of the schematics.  Please let me know if anything needs to be configured differently or if you have any best practices suggestions.

    Reset

    JTAG

    Clock

    VDD and VDDIO

  • Hi,

    At a glance, nothing looks unusual, but it would be good to have oscilloscope captures of these important signals as well. This way we could know if we need to focus on a certain area.

    Best Regards,

    Ben Collier

  • Can you describe what I should expect to see at each of these when JTAG is working properly?

  • Could the 10k pull-up on TDO be causing a problem? Should that 2.2k like TDI and TMS?

  • How about R37 on TCK?

  • Hi Mark,

    I would be looking for unexpected glitches, droops, or spikes in the VDDIO, VDD, XRS, and XCLKOUT signals. 

    I do not think that your issue is related to the JTAG signals since you are able to pass when testing connection and connect to the device, so the resistors should all be ok.

    In addition to the oscilloscope captures, are you able to share screenshots of the errors that you see?

    When you encounter this error, could you also try going to View > Target Configurations, then right-click on the Target Configuration that you are using and select launch target configuration. 

    Then could you right-click on the C28xx core in the debug menu and select Connect Target? 

    If you get to this stage, could you try loading your .out file by clicking the load program button and browsing to your file? 

    When you encounter an error in this process, please take a screenshot and post it here. It would be helpful to confirm if your problem is with connecting to the device, or if your problem is related to flashing.

    One last thing to try could be manually connecting the XRSn pin to ground once your device is in the problem state. It would be helpful to know if a XRS reset will bring the device out of the bad state, or if only power-on reset will help. 

    Best Regards,

    Ben Collier

  • A screenshot of error

    View > Target Configurations, right-click on the Target Configuration that I’m using and select launch target configuration. 

    Right-click on the C28xx core in the debug menu and select Connect Target.  Loaded .out successfully

    Debug > Run, I get this…

  • Interestingly, I set a breakpoint at the call to Sys_Init(); and stepped through initialization then resumed and i didn't see the error.

    I set breakpoints at various locations in initialization, it seemed to be related to timing and GPIO initialization. 

    I then moved GPIO initialization from the first peripheral initialization to the last.  This seems to have "fixed" the issue - but why?  Does this point to anything?

  • Hi Mark,

    Please allow me a couple days to look into this and find an explanation.

    Best Regards,

    Ben Collier

  • I need to clarify.  It "fixed" the ability to build, load, reset, restart, and run.  I can now do that a majority of the time without errors.  However, I now have errors occur on the initial power up (where they were not previously).  I can breakpoint and step through the system init to avoid the errors.  So, there is still something unexpected and unexplained going on that I would like to correct.  Would you be able to support a Teams meeting to see this and help me work through it?  Thanks for your help.

  • Sure Mark, I have sent you a friend request so we can set up a call over private messages. 

  • Ben, thanks for your help today.  Based on our conversation, I took a closer look our GPIO initialization.  On the 0049C launchpad GPIO35 and GPIO37 are not used as TDI and TDO for cJTAG.  Our target board and JTAG uses GPIO35 and GPIO37 TDI and TDO.  However, the initialization routine was unnecessarily unlocking GPIO35 and GPIO37 and configuring them as TDI and TDO.  There must have been interim pin states that were conflicting with the JTAG functionality.  I ended up keeping those two GPIO lock as default (which is TDI and TDO).  That solved this issue.