• Locked Locked
  • Replies 1 reply
  • Subscribers 53 subscribers
  • Views 745 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.

Solved: Upgraded from CCSv5.2 to CCSv5.3 and had troubles with the debug script

David Negro
Intellectual 330 points

I am loading / running an embedded application using a script derived from "loadti.bat".  After upgrading to CCSv5.3 it was longer functioning.  I get the following stack trace:

Opening connection to cpu "ARM9_0"
Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: c:\ti\ccsv5\ccs_base\DebugServer\win32\ti_xpcom.dll
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
at com.ti.xpcom.internal.JavaXPCOMMethods.registerJavaXPCOMMethods(JavaXPCOMMethods.java:53)
at com.ti.xpcom.internal.MozillaImpl.initialize(MozillaImpl.java:49)
at com.ti.xpcom.Mozilla.initialize(Mozilla.java:124)
at com.ti.debug.engine.xpcom.Runtime.startBare(Runtime.java:148)
at com.ti.debug.engine.xpcom.Runtime.createComponent(Runtime.java:196)
at com.ti.debug.engine.impl.Application.<init>(Application.java:105)
at com.ti.debug.engine.cce.CCEDebugEngine.<init>(CCEDebugEngine.java:17)
at com.ti.debug.engine.cce.CCEDebugEngine.instance(CCEDebugEngine.java:50)
at com.ti.debug.engine.scripting.DebugServer.start(DebugServer.java:648)
at com.ti.debug.engine.scripting.DebugServer$SessionFactory.<init>(DebugServer.java:158)
at com.ti.debug.engine.scripting.DebugServer.openSession(DebugServer.java:1339)

...

I compared the loadti example from CCSv5.2 and CCSv5.3 and noticed that it changed slightly.  Here is a snippet of how I fixed it to work with either version of CCS.  Hope this tidbit helps someone else.

set XPCOMRUNTIME=
if not exist "%DEBUGSERVER_ROOT%\win32\ti_xpcom.dll" goto noXPCOMRUNTIME
set XPCOMRUNTIME=-DXPCOM.RUNTIME="%DEBUGSERVER_ROOT%\win32"
:noXPCOMRUNTIME


REM Run generic loader.
CMD /C java.exe %XPCOMRUNTIME% -cp "!RHINO_JAR!;!SCRIPTING_JAR!" !RHINO_SHELL! "!LOADTI_JS!" %PARAM01% %PARAM02% %PARAM03% %PARAM04% %PARAM05% %PARAM06% %PARAM07% %PARAM08% %PARAM09% %PARAM10% %PARAM11% %PARAM12% %PARAM13% %PARAM14% %PARAM15% %PARAM16% %PARAM17% %PARAM18% %PARAM19% %PARAM20% %PARAM21% %PARAM22% %PARAM23% %PARAM24% %PARAM25% %PARAM26% %PARAM27% %PARAM28% %PARAM29% %PARAM30% %PARAM31% %PARAM32% %PARAM33% %PARAM34% %PARAM35% %PARAM36% %PARAM37% %PARAM38% %PARAM39% %PARAM40%

  • TI__Guru**** 483141 points

    David,

    Thanks for sharing your experience and your solution to other here.

    As you found out, it is important for people who are using custom version of the dss.bat or loadti.bat to keep up with the changes made to the official versions of those files when they update CCS to the newer releases. It is a common gotcha.

    Thanks

    ki