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.

TMDSEMU110-U: Connection Issue TMSF28075

Part Number: TMDSEMU110-U
Other Parts Discussed in Thread: TEST, XDS100,
256 / 5000

Risultati della traduzione

I bought a new XDS110 emulator and once connected to the PC on which I am using Code Composer Studio 10.4.0.00006 it asked me to update the firmware.
After software update, trying to launch debug I get this message
The old emulator updated with the same firmware version works fine.

I have tried with a second XDS110 but the result is the same error.
What is really even stranger is that the both new emulators connected to another PC work correctly.
What can I do ?
  • Massimo,

    That is odd, the fact that the emulator works on another PC would suggest that the first PC has some mis-match of FW revision files to what is on the emulator.

    Let's try to update the XDS110 FW manually to the latest rev of FW and see if that fixes things(or lets it update again, etc).

    Instructions are here: https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds110.html (search for Manual Update)

    My files were in this path C:\ti\ccs1000\ccs\ccs_base\common\uscif\xds110\

    Best,

    Matthew

  • I already made it without success.

    I download also the new CCS 11, but the problem is still the same.

    What I can do ?

  • Massimo,

    Can you advise on the latest version of FW on the bad setup in the CCS 11 directory above?

    Can you also run the cmd line code: C:\ti\ccs1040\ccs\base\common\uscif\xds110>xdsdfu -e and post back the output of the command window here?

    Best,

    Matthew

  • This is what I have in CCS 10.4 with good emulator

    This is what I have in CCS 11 with good emulator

    This is what I have in CCS 11 with bad emulator

  • Massimo,

    I'm going to loop in some of the CCS folks to see if they have some ideas.  From the screenshots above everything looks good.

    Best.

    Matthew

  • Massimo,

    Just to confirm, when moving between the 2 PCs, there are no differences, i.e. same USB cable and same target board?  This sounds like a Windows Environment issue, but want to lock down these points before proceeding down that path.

    Best,

    Matthew

  • Confirmed.

    I change only the PC

  • Hi,

    I made some test following the suggested guide without success.

    The HW could not be the problem because the same HW is working on a different PC.

    Below results of Connection Test with different configuration

    PC BAD - XDS100 OK

    [Start: Texas Instruments XDS110 USB Debug Probe_0]

     

    Execute the command:

     

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

     

    [Result]

     

     

    -----[Print the board config pathname(s)]------------------------------------

     

    C:\Users\massimo\AppData\Local\TEXASI~1\

        CCS\ccs1100\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 'jioxds110.dll'.

    The library build date was 'Oct  8 2021'.

    The library build time was '13:26:36'.

    The library package version is '9.5.0.00143'.

    The library component version is '35.35.0.0'.

    The controller does not use a programmable FPGA.

    The controller has a version number of '5' (0x00000005).

    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 XDS110 with USB interface.

    The link from controller to target is direct (without cable).

    The software is configured for XDS110 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).

     

    -----[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 XDS110 USB Debug Probe_0]

     

     

    PC BAD - XDS100 BAD

     

     

    [Start: Texas Instruments XDS110 USB Debug Probe_0]

     

    Execute the command:

     

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

     

    [Result]

     

     

    -----[Print the board config pathname(s)]------------------------------------

     

    C:\Users\massimo\AppData\Local\TEXASI~1\

        CCS\ccs1100\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 'jioxds110.dll'.

    The library build date was 'Oct  8 2021'.

    The library build time was '13:26:36'.

    The library package version is '9.5.0.00143'.

    The library component version is '35.35.0.0'.

    The controller does not use a programmable FPGA.

    The controller has a version number of '5' (0x00000005).

    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 XDS110 with USB interface.

    The link from controller to target is direct (without cable).

    The software is configured for XDS110 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).

     

    -----[An error has occurred and this utility has aborted]--------------------

     

    This error is generated by TI's USCIF driver or utilities.

     

    The value is '-233' (0xffffff17).

    The title is 'SC_ERR_PATH_BROKEN'.

     

    The explanation is:

    The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.

    An attempt to scan the JTAG scan-path has failed.

    The target's JTAG scan-path appears to be broken

    with a stuck-at-ones or stuck-at-zero fault.

     

    [End: Texas Instruments XDS110 USB Debug Probe_0]

    PC OK- XDS100 BAD

    [Start: Texas Instruments XDS110 USB Debug Probe_0]

     

    Execute the command:

     

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

     

    [Result]

     

     

    -----[Print the board config pathname(s)]------------------------------------

     

    C:\Users\massimo\AppData\Local\TEXASI~1\

        CCS\ccs1100\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 'jioxds110.dll'.

    The library build date was 'Oct  8 2021'.

    The library build time was '13:26:36'.

    The library package version is '9.5.0.00143'.

    The library component version is '35.35.0.0'.

    The controller does not use a programmable FPGA.

    The controller has a version number of '5' (0x00000005).

    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 XDS110 with USB interface.

    The link from controller to target is direct (without cable).

    The software is configured for XDS110 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).

     

    -----[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 XDS110 USB Debug Probe_0]

  • Massimo,

    Thanks for the additional data, I've asked some others to take a look and weigh in.  Please give us another day to respond.

    Best,

    Matthew

  • Hello Massimo,

    I'm unclear what you mean by:

    PC OK- XDS100 BAD

    Can you clarify what you mean by "OK" and "BAD"?

    Does PC "OK" refers to the PC you mentioned in the other PCs as mentioned in:

    What is really even stranger is that the both new emulators connected to another PC work correctly.

    And PC "BAD" is the original PC with the issue with the new emulators but the old emulators works fine?

    The old emulator updated with the same firmware version works fine.

    And XDS110 (I assume "XDS100" is a typo) "OK" refers to the original old emulator that work on both "OK" and "BAD" PCs as mentioned below:

    The old emulator updated with the same firmware version works fine.

    And XDS110 "BAD" refers to the new emulators that only works with the PC "OK" machines but not with the original PC "BAD"?

    I bought a new XDS110 emulator and once connected to the PC on which I am using Code Composer Studio 10.4.0.00006 it asked me to update the firmware.
    After software update, trying to launch debug I get this message

    Thanks

    ki

  • Sorry for the delay, but I was out of the office.

    On my first PC I'm working correctly with an old emulator, but utilizing a new one I receive the following message

    On a second computer with both emulator I'm able to flash device (load the program) but only with old one I'm really abe to emulate the software without disconnection.

    All the test I made are with same cable and same HW board, what is changing is only the emulator.

    I try to modify on my HW board the value of the pull-down resistor on TRST, moving from 2.2K to 4.7K

    After this modification all emulators are working with both PC.

    What is strange is that we are producing from many years boards with 2.2K as suggested without the problem

    What is the possible issue to increase this resistor value

    Thank you

  • I try to modify on my HW board the value of the pull-down resistor on TRST, moving from 2.2K to 4.7K

    Others have reported that with the recommended 2.2K pull-down, the XDS110 is unable to drive TRST high. E.g. 
    CCS/TMDSEMU110-U: XDS110 not working, but my XDS100v2 works fine.

    The schematic of the TMDSEMU110-U isn't publicly available, so don't know which device in the XDS110 drives the TRST signal and what drive strength the XDS110 has on TRST.

  • Clear, 

    But now my questions is different.

    What could happen on the filed with a HW board that utilizes 4.7k instead of 2.2k as suggested from your technical document ?

    Thank you

  • Massimo,

    There is slightly more risk of noise effecting TRSTn and pulling it high with a weaker pull-down. With that said, 4.7k used to be our recommendation for JTAG pins, so it should be relatively safe change.

    Realizing that this is a TI made emulator, I'm not sure how a different PC would effect the drive strength of the XDS110 buffers.  I've looked at the internal BOM and this also has not changed either recently or over time. 

    Appreciate any thoughts based on your experience Massimo and Chester.

    Best,

    Matthew

  • Thank you for the feedback.

    Now I have on other issue.

    I tested the two emulators with a different project and different HW.

    The old emulator is working fine, the new one is giving my this error.

    Any Idea ?

  • Massimo,

    Are you using the ccxml to launch the debugger or the "debug" icon in CCS that builds/launches/loads the project?  I'd like to use the ccxml file method(right click and launch debug session) if you are not already doing so to make sure the issue is with the debugger and not the project.

    Best,

    Matthew

  • I made test on the same computer with the same project.

    The only difference is one more time the emulator

  • I try to modify on my HW board the value of the pull-down resistor on TRST, moving from 2.2K to 4.7K

    After this modification all emulators are working with both PC.

    To confirm, both old and new XDS110 probe now works using the original board after modifying the board as mentioned above

    I tested the two emulators with a different project and different HW.

    Now when using the same probes with a different HW, you have issues with the new probe again?

  • I made a test on a different HW board utilizing also a different software project one PC and two emulators.

    The old emulator works fine.

    With the new one I recieve this error message

  • The old emulator works fine.

    With the new one I recieve this error message

    Yes I understood that part. My question was I wanted to confirm that the new emulator now works with the original HW after moidfying the pull-down risistor for TRST.

  • Yes,

    this is the strange thing

  • Thanks for confirming. Does the new HW also have the modification regarding the resistor?

  • YEs,

    I try also to move from 4k7 to 10k.

    Problem is the same.

  • Massimo,

    Thanks for your patience with us here, this is something we are still trying to understand on our end as well.  Could you just remove the pulldown entirely and see if that has any effect.  While this is not recommended for a production environment for the sake of getting a connection with this emulator pod want to see if that fixes anything.  There is a very weak internal PD inside the device that should provide some stability in a lab environment.

    Best,

    Matthew

  • Massimo - can you try one last thing? Can you take the ribbon cable on the old (working) probe and use it with the new probe? 

  • I try to exchange the ribbon cable, but the problem is the same.

    I try also to remove the pull down resistor on TRST but also in this case the old emulator is working fine and with the new one I receive one of the follwing message

  • Massimo,

    When you remove the PD resistor on TRSTn, do you have the emulator plugged in when you power the device?  There is an internal PD that should help keep TRSTn pin stable, but the emulator would need to be connected. 

    In general we want to avoid a floating TRSTn during power up, but while debugging this issue this is fine from a PCB perspective.

    Did you purchase the new emulator through TI.com or from a distributor?  I'd like to see if we can do an exchange, but I really want to make sure the non working emulator gets back to us for some debug locally to root cause this if possible.

    Best,

    Matthew

  • Matthew,

    I try on both conditions (power on with emulator connected and without emulator.

    I don't think that problem could be related to emulator HW, also because I tested with two new units and the problem is the same. Only the old emulator is working.

    If I try with same HW board, same CCS Project on a different PC all 3 emulators are working fine.

    I hope this will help you.

    I need to find a solution ASAP.

  • Massimo,

    Thanks for clarifying your setup; agree that the PC dependency would appear to rule out a HW issue with the emulators.  I know this is a pain, but would it be possible to remove and re-install the XDS110 drivers from your machine?

    To reinstall the Windows device drivers

    • Open the Windows Control Panel
    • Expand the node Texas Instruments Debug Probes
    • Right-click on node XDS110 Class Data Port
    • Select Update Driver SoftwareBrowse my computer for driver software
    • Select Let me pick from a list of device drivers on my computer. If the drivers are already installed, the XDS110 Class Data Port Version: M.m.m.m [mm/dd/yyyy] will be shown. Select this one. Otherwise, repeat but skip this step.
    • Click on Browse and select the directory C:\ti\ccsv8\ccs_base\emulation\windows\xds110_drivers
    • Repeat for XDS110 Class Debug Probe

    That should get you the same driver as installed by CCS.

    If Windows refuses to update the driver, they need to be fully removed.

    • Right-click on node XDS110 Class Data Port
    • Select Uninstall...
    • Check the box Delete the driver software for this device and click OK
    • Repeat for XDS110 Class Debug Probe
    • Do the procedure above to reinstall the drivers

    Best,
    Matthew

  • I try both (update and uninstall) but the problem is the same.

    Now I'm receiving this error message

  • Massimo,

    Thanks for doing this, this error is typically caused by the DCSM(Security Module) terminating the emulation connection.  Can you place the device in Wait Boot mode and see if this resolves the issue?

  • I tried.

    In this case I received or the same error or something different.

    case 1

    C28xx_CPU1: GEL Output:

    Memory Map Initialization Complete

    C28xx_CPU1: 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.5.0.00143)

    C28xx_CPU1: Trouble Halting Target CPU: (Error -1135 @ 0x90224) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.5.0.00143)

    C28xx_CPU1: Unable to determine target status after 20 attempts

    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

    case 2

    C28xx_CPU1: GEL Output:

    Memory Map Initialization Complete

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

    C28xx_CPU1: Trouble Halting Target CPU: (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.5.0.00143)

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

    C28xx_CPU1: Unable to determine target status after 20 attempts

    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

    I need to fix this issue ASAP.

    Thank you

  • Massimo,

    We're not sure what the issue could be at this point; the fact that the XDS110 works correctly with a different PC would imply there is something different about the non-working PC/system.  From a HW perspective are there multiple USB ports on the non-working PC and have we tried them to see if there is any difference in behavior?

    Best,

    Matthew

  • I tried on different USB ports but result is the same.

  • Massimo,

    Sorry for the delay with the holidays in the US.

    Let me re-summarize to make sure we are on the same page:

    1)With the original HW, we were able to make the new emulators work across all PCs with the change in TRSTn resistor value; increasing the PD from 2.2k to 4.7kohm(decreasing the PD strength)

    2)Now, with new HW the problem has returned, and changing the PD value has no effect.

    3)With the new HW the old emulator is fine

    4)With the new HW the new emulators won't connect, is this on all PCs on just on certain PCs

    Best,

    Matthew

  • The problem is still with one PC and the new emulator.

    I saw on your web site that there is a new CCS version.

    Do you sugest me to upgrade it ?

    Could this help in my issue ?

  • Massimo,

    I think it would be good to try this out, it would get us all on the main/latest version of the tool's code base.

    Best,

    Matthew

  • Hi Matthew,

    I upgraded CCS to the last version 11.1.0.00011.

    The problem is still the same.

    I have two projects (Project 1 and Project 2) working on different HW (HW1 and HW2).

    With the old emulators all PC are working fine with a TRST value of 2.2k, the same I’m utilizing from many years. I’m able to program flash and debug code correctly.

    With the two new emulators I tested I need to increase this resistor value, in particular this is the situation I verified on HW-1.

    Working on HW-2 the situation is reported in the below table.

    HW-1   (TRSR Resistor 4.7kΩ)

     

    Project 1

    PC-1

    PC-2

     

     

     

    ORIGINAL TMDSEMU110-U

    Serial# 6503300394

    OK

    OK

    NEW TMDSEMU110-U

    Serial# 6718100596

    OK

    OK

    NEW TMDSEMU110-U

    Serial# 6718101178

    OK

    OK

     

    Working on HW-2 the situation is reported in the below table.

    HW-2   (TRSR Resistor 47kΩ)

     

    Project 2

    PC-1

    PC-2

     

     

     

    ORIGINAL TMDSEMU110-U

    Serial# 6503300394

    OK

    OK

    NEW TMDSEMU110-U

    Serial# 6718100596

    Error -1156

    Error -1050

    OK

    NEW TMDSEMU110-U

    Serial# 6718101178

    Error -1156

    Error -1050

    OK

     

    I really need your help to fix this issue.

    Please give me suggestions ASAP.

    Thank you.

  • Massimo,

    For HW1 and HW2; is the C2000 the same PN or are there 2 different MCU types on the different HW platform?

    Best,

    Matthew

  • Massimo,

    Some more questions:

    1)Is the layout/distance of the JTAG connections different between the 2 HW?

    2)For the error 1156, this indicates a low power state.  Can you put a meter or scope on the PD pin of the JTAG (pin 5) on the different boards/emulators and let me know what we measure?  This signal should be connected to the VDDIO plane of the PCB.

    Best,

    Matthew

  • HW1 and HW2 have the same MCU and JTAG layout is very similar.

    On all the situation (different PC vs different emulators) the value on PD is always 3.290 V.

    With bad emulators and bad PC the error message is not always 1156, but different I receive this morning 1135

    Waiting for your replay I remain.

  • Massimo,

    Please give me another day to think about this.  This is a challenging debug given the different factors; and there doesn't appear to be a single factor causing all of this either.  This is not something we have encountered before in our group.

    Any other distinction you can think of between the 2 PCs, i.e. one is USB 3.0 vs 2.0, etc?  I'm not an expert here, but just trying to narrow anything else down.

    Best,

    Matthew

  • I tried USB 2.0 and USB 3.0.

    Result is the same

  • Massimo,

    We may have already tried this when we began the investigation, but I'd like to make sure.  On the HW-2 can you place the device in Wait Boot mode and see if this changes anything?

    Even if you don't have a CSM password, the device can still have issues connecting if it begins to execute from flash if the device unlock procedure doesn't happen.  Wait Boot will take care of this.

    My theory would be that a combination of effects on PC-1/new XDS110/HW are slowing the connection process and the MCU is executing a different region of code than with the other combos.

    Let me know what you observe by trying Wait Boot Mode.

    Best,

    Matthew

  • I tried and in this case on PC1 I received always error -1156

    The voltage value on PD is correct.

  • Massimo,

    Thanks for trying this, if the device is wait boot mode there should be no way there is any activity that would prevent a connection.

    For my knowledge, does the power supply to the PCB have any relationship to the PC, i.e. using the 5V of the USB to supply power?  Or is the power domain completely different, i.e. from a supply or wall plug.

    Best,

    Matthew

  • This is the setting I have

  • Massimo,

    Can you share with me how the C2000/PCB(not the JTAG debugger) is powered?  Is there any common connection with the PC?

    Best,
    Matthew