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.

DSS with Jython on Linux

I'm working on a stand along debug script which will run on Ubuntu Linux. Our preferred scripting language is Python so I've started with Jython. I'm following the example found at and have stumbled at

debugSession = debugServer.openSession()

Complete output from the script is

hbarta@itws007:~/sample$ cat load.err
"my" variable $jythonHome masks earlier declaration in same scope at /usr/bin/jython line 15.
traceSetFileLevel: ENTRY sLevel: ALL
traceSetFileLevel: RETURN
getServer: ENTRY sServerName: DebugServer.1
getServer: Getting definition for: DebugServer.1
getServer: Constructing server
getServer: RETURN com.ti.debug.engine.scripting.DebugServer@5707c1cb
setConfig: ENTRY sConfigurationFile: TMS320F28377D.ccxml
setConfig: RETURN
openSession: ENTRY sPattern: .*
start: ENTRY
start: Firing: onServerStarting()
start: Connecting to XPCOM DebugServer
Java HotSpot(TM) 64-Bit Server VM warning: You have loaded library /opt/ti/ccsv6/ccs_base/DebugServer/bin/libti_xpcom.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Traceback (most recent call last):
  File "./load_blinky.jy", line 31, in <module>
    debugSession = debugServer.openSession()
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1938)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1821)
        at java.lang.Runtime.load0(Runtime.java:809)
        at java.lang.System.load(System.java:1086)
        at com.ti.xpcom.internal.JavaXPCOMMethods.registerJavaXPCOMMethods(JavaXPCOMMethods.java:53)
        at com.ti.xpcom.internal.MozillaImpl.initialize(MozillaImpl.java:52)
        at com.ti.xpcom.Mozilla.initialize(Mozilla.java:124)
        at com.ti.debug.engine.xpcom.Runtime.startBare(Runtime.java:122)
        at com.ti.debug.engine.xpcom.Runtime.createComponent(Runtime.java:170)
        at com.ti.debug.engine.impl.Application.<init>(Application.java:106)
        at com.ti.debug.engine.cce.CCEDebugEngine.<init>(CCEDebugEngine.java:15)
        at com.ti.debug.engine.cce.CCEDebugEngine.instance(CCEDebugEngine.java:48)
        at com.ti.debug.engine.scripting.DebugServer.start(DebugServer.java:633)
        at com.ti.debug.engine.scripting.DebugServer$SessionFactory.<init>(DebugServer.java:161)
        at com.ti.debug.engine.scripting.DebugServer.openSession(DebugServer.java:1116)
        at com.ti.debug.engine.scripting.DebugServer.openSession(DebugServer.java:1081)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)

java.lang.UnsatisfiedLinkError: java.lang.UnsatisfiedLinkError: /opt/ti/ccsv6/ccs_base/DebugServer/bin/libti_xpcom.so: /opt/ti/ccsv6/ccs_base/DebugServer/bin/libti_xpcom.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
hbarta@itws007:~/sample$ 

The script itself is

#!/usr/bin/jython

"""
Script to load an executable on the controlcard
From instructions at processors.wiki.ti.com/.../Python_Scripting_with_DSS
"""

from java.lang import *
from java.util import *
from com.ti.debug.engine.scripting import *
from com.ti.ccstudio.scripting.environment import *

# Create our scripting environment object - which is the main entry point into any script and
# the factory for creating other Scriptable Servers and Sessions
script = ScriptingEnvironment.instance()
 
# Create a log file in the current directory to log script execution
script.traceBegin("dss_py.xml", "DefaultStylesheet.xsl")

# Set our TimeOut
script.setScriptTimeout(15000)
 
# Log everything
script.traceSetConsoleLevel(TraceLevel.ALL)
script.traceSetFileLevel(TraceLevel.ALL)
 
# Get the Debug Server and start a Debug Session
debugServer = script.getServer("DebugServer.1")
debugServer.setConfig("blinky_cpu01/targetConfigs/TMS320F28377D.ccxml");
 
debugSession = debugServer.openSession()

(We are using an F28379 controlCARD for initial testing.)

Various versions:

hbarta@itws007:~/sample$ uname -a
Linux itws007 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
hbarta@itws007:~/sample$ jython --version
"my" variable $jythonHome masks earlier declaration in same scope at /usr/bin/jython line 15.
Jython 2.5.3
hbarta@itws007:~/sample$ java -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
hbarta@itws007:~/sample$ javac -version
javac 1.7.0_111
hbarta@itws007:~/sample$ 

CCS  Version: 6.1.3.00034

I'm concerned about the version discrepancy between java and javac but I do not know if that matters for this.


I have no idea what the error message means other than to speculate it is a 32 bit vs. 64 bit mismatch. We are running on a 64 bit installation.

Please let me know if further information is needed.


Thanks!

  • Hi Hank,

    Hank Barta said:
    I have no idea what the error message means other than to speculate it is a 32 bit vs. 64 bit mismatch. We are running on a 64 bit installation.

    All CCS versions on Windows and Linux prior to 6.2.0 are 32-bit applications with a dependency on a 32-bit JRE. Trying to use a 64-bit JRE with CCS/DSS will not work. CCS ships with its own JRE that it will always default to that running CCS. But for DSS, it depends on how the environment is configured.

    Since you have a 64-bit OS and configured for a 64-bit JRE, you may want to try using CCSv6.2.0, which is the first version to be 64-bit.

    Thanks

    ki

  • Thanks again for the quick reply. I really hope you know how helpful that is.

    -hank
  • Thanks Hank, Glad to help. Please let me know how it goes with 6.2.0. I've not had a chance to try DSS w/jython with CCSv6.2.0 so I'm curious.

    Thanks
    ki
  • 
    

    Hi ki,

    It looks like upgrading to 6.2 fixed this problem. That error no longer appears and with the change to the last line of the script to

    debugSession = debugServer.openSession("Texas Instruments XDS100v2 USB Debug Probe_0/C28xx_CPU1")
    

    It now executes through w/out errors (and 62 lines of verbosity. ;) )

    thanks,

    hank

  • One additional comment. The example code at processors.wiki.ti.com/.../Python_Scripting_with_DSS is missing the connect() call. This goes way back apparently: e2e.ti.com/.../202564 The example code in .../ccsv6/ccs_base/scripting/examples/DebugServerExamples/LoadProgram.js is also in error.

    thanks,
    hank
  • Right, thanks Hank for the reminder. I need to update that example. The reason for it is that many of those old DSS example scripts that come with DSS use a simulator target and simulators are "always" connected so the script is missing that call. It's even more confusing because CCS no longer supports simulators but the examples are still configured for them (and yes there is a defect filed against DSS for this that we plan to address with CCSv7). Sorry for all the trouble.

    ki