• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 81 subscribers
  • Views 1522 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

[FAQ] CCS/LAUNCHXL-F280049C: ADVISEMENT: EMUPack 8.0.903.4 incompatible with LAUNCHXL-F280049C

CCS/TMS320F280049C: XDS110 driver version 2.3.0.18 does not recognize my TMS320F280049C

Kevin McWithey1
Prodigy 40 points
Part Number: TMS320F280049C
Other Parts Discussed in Thread: UNIFLASH,

Tool/software: Code Composer Studio

I have been developing and debugging our board with the TMS320F280049C and using CCSv8.3.0.00009 for months.  I updated CCSV8 and now I get error messages when attempting to debug.  I also installed CCSv9 and I get the same error.  I also tried the latest Uniflash and I get the same error. It appears to be related to the XDS Emulation Software V8.1.0.00005.  Reverting back to CCSv8.3.0.00009 with emu pack v8.0.903.4 fixes the problems.   

Working XDS110 firmware version number is 2.3.0.16

Not Working XDS110 firmware version number is 2.3.0.18

Error is:

Error connecting to the target:
(Error -1265 @ 0x0)
Device ID is not recognized or is not supported by driver. Confirm device and debug probe configuration is correct, or update device driver.
(Emulation package 8.1.0.00007)

Test connection log from .ccxml opened in CCSv9 is:

[Start: Texas Instruments XDS110 USB Debug Probe]

Execute the command:

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

[Result]


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

C:\Users\kevin\AppData\Local\TEXASI~1\CCS\
ccs901\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 'Mar 25 2019'.
The library build time was '17:36:26'.
The library package version is '8.1.0.00007'.
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 '-230' (0xffffff1a).
The title is 'SC_ERR_PATH_MEASURE'.

The explanation is:
The measured lengths of the JTAG IR and DR scan-paths are invalid.
This indicates that an error exists in the link-delay or scan-path.

[End: Texas Instruments XDS110 USB Debug Probe]

I am up and running again using the old stuff.  Only three hours wasted.  How do I get the new stuff working?

  • 0
    TI__Guru**** 168317 points

    Hi,

    Would you mind double-checking the JTAG mode of operation of your configuration?

    The reason is that I can get the same error as you if I set it erroneously to JTAG (1149.1) SWD and cJTAG are disabled. 

    If I set it to cJTAG (1149.7) 2-pin advanced modes, the connection tests complete successfully.

    Regards,

    Rafael

  • 0 in reply to desouza
    Prodigy 40 points

    No luck.  I also tried it through the JTAG port (not the onboard) on the "C2000 F28004x controlCard B" and it has the same problem.

  • 0 in reply to Kevin McWithey1
    TI__Guru**** 168317 points

    Hi,

    Unfortunately I can't seem to reproduce the same problem. I am running this board with several versions of CCS/emupack and nothing is really failing at the moment. I will keep trying to "break" my system here. 

    Since you have your system running, it certainly seems to be an issue with both the software and firmware.

    Just a clarification: you are manually downgrading the firmware, right? 

    Note that we don’t automatically revert the software unless there’s been a major change.  We try to make all changes backwards compatible to ensure this works. If we ever need to make a change that is backwards compatible, then the major version numbers will change as a flag that it can’t work.

    Examples:

    CCS supports firmware 2.3.0.12, XDS110 has firmware 2.3.0.8 → XDS110 will be updated to 2.3.0.12
    CCS supports firmware 2.3.0.12, XDS110 has firmware 2.3.0.14 → XDS110 will not be reverted
    CCS supports firmware 2.3.0.12, XDS110 has firmware 2.4.0.1 → XDS110 will be reverted to 2.3.0.12

    Regards,

    Rafael

  • 0 in reply to desouza
    Prodigy 40 points

    Yes, I am manually reverting the firmware back using the command line tool.

  • 0 in reply to Kevin McWithey1
    TI__Guru**** 168317 points

    Hi,

    Sorry, I got confused by the various releases of the TI Emulators package. 

    You need to update your version of the TI Emulators package to 8.1.0.00012 to connect to the F280049C board. 

    Check the two short clips below, where I illustrate the process. 

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Prodigy 40 points

    That did not solve the issue.

    I have done some more testing and the new xds drivers do not work with the isolation adapter I am using.  The old drivers work with the isolation adapter.

    Isolation adapter is blackhawk BH-ADP-ISO20.

    We were having random failures of the XDS110 until we started using the isolation adapter.

    I am able to connect with the new drivers without the isolation adapter.  I will continue using the old drivers so I can use the isolation adapter and do not damage anymore XDS110 emulators.


  • 0 in reply to Kevin McWithey1
    TI__Guru**** 168317 points

    Hi,

    Thank you for reporting back your findings. The incompatibiility with the isolation adapter itself is something new to me, thus I will try to find out what is the root cause for this. Although I don't have the same adapter as you, I have their other BH-ADP-ISO110 and will do some testing here - although with a different device, given this adapter does not support cJTAG.

    One aspect you could try (if you still want to uncover this) is to reduce the TCLK speed to 1.0MHz or lower - the Isolation adapter tends to add delays to the JTAG signals and, while the prior firmware version works, a very slight delay added may have been enough to trigger the problem in the newer firmware.  

    Hopefully I can try to find something conclusive in this regard. If I find something I will report back on this thread. 

    Regards,

    Rafael

  • 0 in reply to desouza
    TI__Guru**** 168317 points

    Hi,

    One aspect that I was informed yesterday from the development team that did the newer XDS110 emulation package software (emupack). 

    The emupack that ships with CCSv9.0.x versions (8.1.0.00012) has some jitter on the clock edges when running at 2.5MHz (the maximum speed of this version), which may cause very random communication errors with the target. Although errors are not regularly seen with the compact Launchpads, the longer cconnections of custom setups or even the use of isolation adapters can contribute to this problem. 

    The remedy for this is to lower the TCK speed to 1.25MHz. This will reduce the jitter and should warrant a reliable connection. 

    This issue will be fixed in the next release of the emupack, to be available publicly soon. This next release will have a default TCLK speed of 8.0MHz, but it can be safely lowered to the same 2.5MHz of previous versions but this time with a stable TCLK signal. 

    In the light of this, I apologize for the inconvenience. 

    Regards,

    Rafael