• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 1070 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/TMDSEMU110-U: module xml files used with the debug prob in a new location

Paul Lane
Prodigy 210 points
Part Number: TMDSEMU110-U
Other Parts Discussed in Thread: F28M36P63C2

Tool/software: Code Composer Studio

Hello

OS: Ubuntu 19.10

Probe: XDS110 Debug Probe

CCS Version: 9.3.0.00012

Chip: F28M36P63C2

In CCS, Project>>Properties>>General>>Connection>>Texas Instruments XDS110 Debug Probe, Click Verify

Error parsing file:
Fatal Error at (0, 0): An exception occurred! Type:RuntimeException, 
Message:The primary document entity could not be opened. 

Id=/opt/ti/ccs930/ccs/ccs_base/common/Modules/C2000/C2000_ADC_Type3_M3_Result_Registers.xml 

while parsing file: 
/opt/ti/ccs930/ccs/ccs_base/common/Modules/C2000/C2000_ADC_Type3_M3_Result_Registers.xml

While searching for this file, the actual location is: 

/opt/ti/ccs930/ccs/ccs_base/common/targetdb/Modules/C2000

We were originally developing on windows, and switched to Ubuntu, and most likely went from ccs9 something to the current 9.3.0.00012 version we have. Note the probe is not connected to the board, only the computer over USB.

Is this a windows vs linux file path?

How do I correct this search path? To work on both platforms

Does something need to be updated?

Thank you,

  • 0
    TI__Guru**** 171254 points

    Hi,

    I see you installed CCS as a superuser. Unfortunately there is an outstanding bug in both CCSv9.2.0 and CCSv9.3.0 that sets incorrect permissions to several files inside the CCS install directory. 

    In this case, check the section Setting the correct permissions at the CCS Linux Host Support page at:

    https://software-dl.ti.com/ccs/esd/documents/ccsv9_linux_host_support.html 

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Prodigy 210 points

    In the link provided I do not see reference to "Setting the correct permissions", "Setting" is only in the proxy section, and "permissions" does not exist on the page.

    Also a bug with giving the wrong permissions does not seem related to the file having a different path? Even if the permission was correct the file is in a location other that where is being searched.

    Thank you,

  • 0 in reply to Paul Lane
    TI__Guru**** 171254 points

    Hi,

    Paul Lane said:
    In the link provided I do not see reference to "Setting the correct permissions", "Setting" is only in the proxy section, and "permissions" does not exist on the page.

    Can you access this direct link? 

    https://software-dl.ti.com/ccs/esd/documents/ccsv9_linux_host_support.html#setting-the-correct-permissions

    The link should take you to the bottom of the page I sent before:

    Paul Lane said:
    Also a bug with giving the wrong permissions does not seem related to the file having a different path?

    The strange path is how it was parsed to comprise the error message - once the permissions are set, the test connection will work.

    Regards,

    Rafael

  • 0 in reply to desouza
    Prodigy 210 points

    There seems to be a problem with both links, they go to the same place, but I am not seeing the last section on my page? I can somewhat see the content from your post and do not see similar content on the link.

    Update, following the steps in the screenshot I get the same results of the original question.

    Command run below

    pwd
/opt/ti/ccs930/ccs


sudo chmod -Rf g+rX o+rX *

  • 0 in reply to Paul Lane
    TI__Guru**** 171254 points

    Hi,

    If you haven't done so, I would try to restart CCS. Before I posted my last reply, I tested the setup and the workaround worked in my host here (CCSv9.3.0 with Ubuntu 19.10 and the same device/Debug Probe). 

    With this, I am unsure what may be going on in your case. Can you double-check to see if the directory /opt/ti/ccs930/ccs/ccs_base\/ommon/Modules/C2000 and the files inside of it have the permissions drwxr-xr-x?

    I will keep trying to see if there are any other conditions that could trigger that and report back if I find anything. 

    Regards,

    Rafael

  • 0 in reply to desouza
    Prodigy 210 points

    Before permission change:

    /opt/ti/ccs930/ccs$ ls -la
total 7636
drwxr-xr-x 13 root root    4096 Feb 27 17:10 .
drwxr-xr-x  4 root root    4096 Feb 27 17:09 ..
drwxr-xr-x 17 root root    4096 Dec  4 18:56 ccs_base
drwxr-xr-x  2 root root    4096 Feb 27 17:08 doc
drwxr-xr-x 11 root root    4096 Feb 27 17:09 eclipse
-rw-r--r--  1 root root    1182 Feb 27 17:09 .installedComponents.properties
-rw-r--r--  1 root root      57 Feb 27 17:09 .installedProductFamilies
drwxr-xr-x  3 root root    4096 Feb 27 17:07 install_info
drwxr-xr-x  3 root root    4096 Feb 27 17:06 install_logs
drwxr-xr-x  2 root root    4096 Feb 27 17:09 install_scripts
drwxr-xr-x  3 root root    4096 Feb 27 17:05 tirex3
drwxr-xr-x  3 root root    4096 Feb 27 17:05 tirex4
drwxr-xr-x  4 root root    4096 Feb 27 17:04 tools
-rwx------  1 root root 7552524 Feb 27 17:09 uninstall_ccs.bin
-rw-------  1 root root  201026 Feb 27 17:10 uninstall_ccs.dat
drwxr-xr-x  2 root root    4096 Feb 27 17:06 uninstallers
drwxr-xr-x  5 root root    4096 Feb 27 17:08 utils

    After permission change:

    /opt/ti/ccs930/ccs$ ls -la
total 7636
drwxr-xr-x 13 root root    4096 Feb 27 17:10 .
drwxr-xr-x  4 root root    4096 Feb 27 17:09 ..
drwxr-xr-x 17 root root    4096 Dec  4 18:56 ccs_base
drwxr-xr-x  2 root root    4096 Feb 27 17:08 doc
drwxr-xr-x 11 root root    4096 Feb 27 17:09 eclipse
-rw-r--r--  1 root root    1182 Feb 27 17:09 .installedComponents.properties
-rw-r--r--  1 root root      57 Feb 27 17:09 .installedProductFamilies
drwxr-xr-x  3 root root    4096 Feb 27 17:07 install_info
drwxr-xr-x  3 root root    4096 Feb 27 17:06 install_logs
drwxr-xr-x  2 root root    4096 Feb 27 17:09 install_scripts
drwxr-xr-x  3 root root    4096 Feb 27 17:05 tirex3
drwxr-xr-x  3 root root    4096 Feb 27 17:05 tirex4
drwxr-xr-x  4 root root    4096 Feb 27 17:04 tools
-rwxr-x---  1 root root 7552524 Feb 27 17:09 uninstall_ccs.bin
-rw-r-----  1 root root  201026 Feb 27 17:10 uninstall_ccs.dat
drwxr-xr-x  2 root root    4096 Feb 27 17:06 uninstallers
drwxr-xr-x  5 root root    4096 Feb 27 17:08 utils

    Nothing appears to have changed because the permissions were correct to begin with.

    CCS is searching for: C2000_ADC_Type3_M3_Result_Registers.xml 

    In the location:

    /opt/ti/ccs930/ccs/ccs_base/common/Modules/C2000/

    The file/folder structure does not exist. This difference in CCS search location and actual file location is not clear how changing the permissions to the actual file location below will change the CCS search path? Unless CCS is doing a broad search and will find the new file location with the permission change?

    The file exists in an alternate location:

    /opt/ti/ccs930/ccs/ccs_base/common/targetdb/Modules/C2000/

    Permissions of the C2000 folder:

    drwxr-x---  2 root root   32768 Feb 27 17:06 C2000

    using sudo -s I can look into the C2000 folder for our file.

    -rw-r--r--  1 root root   2490 Jun 25  2019 C2000_ADC_Type3_M3_Result_Registers.xml

    The folder and file have the incorrect permissions, and trying to run the chmod command suggested in the /opt/ti/ccs930/ccs/ccs_base/common/targetdb/Modules/ location on the /C2000 folder, and on the entire folder with * did not change the permissions.

    Can you confirm the spacing in the command for me? The previous comment I mentioned the sudo chmod command and I think interpreted the screen shot to have spaces in the command although it was hard to tell. 

    sudo chmod -RfSPACEg+rXSPACEo+rX *

    To Highlight I see 2 problems:

    1) CCS Search path for the .xml file is incorrect, and does not exist. The actual file exists elsewhere

    2) The permissions of where the file actually exists has the wrong permissions

    - Attempting to change the permissions with the suggested chmod command is not changing as desired

    Also restarting ccs did not fix the problem.


    Edit: Successfully changed the permissions by including a comma in the command and removing -f which silents error messages.

    /opt/ti/ccs930/ccs/ccs_base/common/targetdb/Modules$ sudo chmod -R g+rX,o+rX *

    Running the test again results in 

    [Start]

Execute the command:

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

[Result]


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

/home/plane/.ti/ccs930/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 'libjioxds110.so'.
The library build date was 'Nov 25 2019'.
The library build time was '15:00:34'.
The library package version is '8.4.0.00006'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
Updating the XDS110 firmware ... complete.

An error occurred while hard opening the controller.

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

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

The value is '-267' (0xfffffef5).
The title is 'SC_ERR_XDS110_TARGET_SUPPLY'.

The explanation is:
The controller could not detect valid target supply. Check target
JTAG connection and/or connection setting specifying voltage level.

[End]

    The test was run with the XDS110 not connected to the board, only connected to the laptop. I will test shortly with the board connected.

    Edit 2: Connecting the board and running the same test produced a different result, I believe if positive.

    [Start]

Execute the command:

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

[Result]


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

/home/plane/.ti/ccs930/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 'libjioxds110.so'.
The library build date was 'Nov 25 2019'.
The library build time was '15:00:34'.
The library package version is '8.4.0.00006'.
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]

  • 0 in reply to Paul Lane
    TI__Guru**** 171254 points

    Hi,

    Thanks for sending the additional considerations. 

    Paul Lane said:
    Edit: Successfully changed the permissions by including a comma in the command and removing -f which silents error messages.

    I apologize; I must be going crazy. I had tested the previous combination numerous times (including while I was replying to you earlier) and it seemed to have worked for me, but now it does not work in any of the platforms I tested. I may have done something else in between and forgot about it. 

    Not only your suggestion works, but you can also issue the following:

    user@host:/opt/ti/ccs930/ccs$ sudo chmod -R go+rX *

    I'll change the page. 

    Paul Lane said:
    Edit 2: Connecting the board and running the same test produced a different result, I believe if positive.

    Yes, that is the expected outcome for a working connection. 

    I apologize again for the confusion. 

    Regards,

    Rafael

    P.S. I split the discussion as the issue is different in nature. The new thread is: https://e2e.ti.com/support/tools/ccs/f/81/t/886638

  • 0 in reply to desouza
    Prodigy 210 points

    I wonder if your test was a false positive? due to having the correct permissions in another file location and the linkage finding/pointing to that one instead of the test dir?

    Edit: I missed your comment about splitting my previous comment into a new thread, Thank you for the help

    I thought I highlighted this issues yesterday, but I guess I did not. The "verify" button worked as previously stated, but when attempting to upload code to the boardccs would crash with a print out to the terminal segmentation fault (core dump). I was unable to open, or decode the .dmp file generated to investigate further.

    Good news, I was able to get CCS working on a windows 10 vm, and upload and benchmark some code. But I would be very much interested to be able to run CCS on linux effectively as we are running linux natively with a windows 10 vm. The current issue with Ubuntu being that ccs is crashing during upload to board.

    Thank you,

  • 0 in reply to Paul Lane
    TI__Guru**** 171254 points

    Hi,

    Thanks for the additional considerations. I can't tell right now if it was a false positive or I added a step that I can't recall right now.

    At any rate, I updated the page with the working configuration and replied to your segfault comments in the other thread. 

    Regards,

    Rafael