• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 53 subscribers
  • Views 2445 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.

CCS: CCS7 headless build

RH2248
Intellectual 290 points
Other Parts Discussed in Thread: CCSTUDIO

Tool/software: Code Composer Studio

Hi everybody,

 

using CCS7 in GUI mode imports and builds the project without problems on Win7 and Win10 server.

However a headless build doesn’t work on the Win10 server machine.

 

Attached is a test project for C2000 with a batch file to reproduce the problem.

 

The reported error on import is:

 

org.eclipse.core.runtime.CoreException:

        at com.ti.ccstudio.buildmodel.BuildModelLoader.preGenerateDynamicBuildDefinitions(BuildModelLoader.java:722)

        at com.ti.ccstudio.project.core.services.ProjectImporter.internalImportProject(ProjectImporter.java:469)

        at com.ti.ccstudio.project.core.services.ProjectImporter.access$1(ProjectImporter.java:407)

        at com.ti.ccstudio.project.core.services.ProjectImporter$1.run(ProjectImporter.java:372)

        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)

        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)

        at com.ti.ccstudio.project.core.services.ProjectImporter.importProject(ProjectImporter.java:370)

       at com.ti.ccstudio.project.core.services.ProjectImporter.importProject(ProjectImporter.java:335)

        at com.ti.ccstudio.apps.internal.project.ProjectImportApp.doRun(ProjectImportApp.java:168)

        at com.ti.ccstudio.apps.internal.BaseHeadlessApp$1.run(BaseHeadlessApp.java:340)

        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)

        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)

        at com.ti.ccstudio.apps.internal.BaseHeadlessApp.internalRun(BaseHeadlessApp.java:338)

        at com.ti.ccstudio.apps.internal.BaseHeadlessApp.start(BaseHeadlessApp.java:260)

        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)

        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)

        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)

        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)

        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)

        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:498)

        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)

        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)

        at org.eclipse.equinox.launcher.Main.run(Main.java:1519)

Caused by: java.lang.NullPointerException

        at com.ti.common.project.core.internal.tools.ADiscoveryManager.getDiscoveryPathSetting(ADiscoveryManager.java:349)

        at com.ti.common.project.core.internal.tools.ADiscoveryManager.getDiscoveryPath(ADiscoveryManager.java:157)

        at com.ti.common.project.core.internal.tools.AToolDiscoveryManager.getToolDiscoveryPath(AToolDiscoveryManager.java:192)

        at com.ti.common.project.core.internal.tools.AToolDiscoveryManager.getToolDiscoverySearchPath(AToolDiscoveryManager.java:181)

        at com.ti.common.project.core.internal.tools.AToolDiscoveryManager.doRefresh(AToolDiscoveryManager.java:157)

        at com.ti.ccstudio.project.core.internal.tools.CodegenToolDiscoveryManager.doRefresh(CodegenToolDiscoveryManager.java:88)

        at com.ti.common.project.core.internal.tools.AToolDiscoveryManager.refresh(AToolDiscoveryManager.java:145)

        at com.ti.common.project.core.internal.tools.AToolDiscoveryManager.initialize(AToolDiscoveryManager.java:114)

        at com.ti.ccstudio.project.core.internal.tools.CodegenToolDiscoveryManager.initialize(CodegenToolDiscoveryManager.java:64)

        at com.ti.ccstudio.project.core.internal.tools.CodegenToolDiscoveryManager.internalGetCodegenTools(CodegenToolDiscoveryManager.java:221)

        at com.ti.ccstudio.project.core.internal.tools.CodegenToolDiscoveryManager.findSupportedCodegenToolVersion(CodegenToolDiscoveryManager.java:286)

        at com.ti.ccstudio.buildmodel.BuildModelLoader.preGenerateDynamicBuildDefinitions(BuildModelLoader.java:705)

        ... 25 more

 

 

CCS version:

7.1.0.00015

 

Java version:

java version "1.8.0_121"

Java(TM) SE Runtime Environment (build 1.8.0_121-b13)

Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

 

Windows version:

Microsoft Windows [Version 10.0.14393] – Server 2016 Standard

 

Any ideas?

 

Best regards

Ralph

4064.Test.zip

  • 0
    TI__Guru**** 173310 points

    RH2248 said:

    using CCS7 in GUI mode imports and builds the project without problems on Win7 and Win10 server.

    However a headless build doesn’t work on the Win10 server machine.

     

    I haven't been able to reproduce this on my Windows 7 machine. I ran the the batch file and it imported and built the project fine.

    Is the error reproducible at your end on any machine other than the Win10 server? And does the error occur only on a specific project or all projects (if you could test 
    with a couple of different projects and let us know that would be helpful).

  • 0 in reply to AartiG
    Intellectual 290 points

    Everything is fine here on different Win7 machines, too.

    Unfortunately I only have this single Win10Server (which is our build server) machine available here at the moment where all projects I tested (2 larger ones and the generated short "hello world" I provided) fail.

    By the way, all 3 projects ran fine on the Win10Server with CCS6.

    Best regards,

    Ralph

  • 0 in reply to RH2248
    TI__Guru**** 173310 points

    RH2248 said:
    Unfortunately I only have this single Win10Server (which is our build server) machine available here at the moment where all projects I tested (2 larger ones and the generated short "hello world" I provided) fail.

    Could it be that the CCSv7 installation on this machine is somehow corrupted? Have you already tried a clean reinstall just to be sure?

  • 0 in reply to AartiG
    Intellectual 290 points
    just re-installed CCS7 and tested again, but no success.

    One thing I realized here: there are some Problems with the OSGI which can be (at least) reduced with adding

    -Dosgi.configuration.area=@user.home/ccsv7_config
    -Dosgi.locking=none

    to ccstudio.ini file together with allowing a full access to C:\ti\ccsv7\eclipse\configuration\org.eclipse.osgi\.manager\.fileTableLock


    Anybody else using Win10Server and willing to test my small reproduction Project from the first post?

    Thank you,
    Ralph
  • 0 in reply to RH2248
    TI__Genius 9175 points

    Hi Ralph, 

    Could you please attach the <workspace>/.metadata/.log file?  It might contain additional information.

    Thanks,

    - Baltasar

  • 0 in reply to Baltasar Belyavsky
    Intellectual 290 points

    Hi Baltasar,

    please find attached the zipped .log file.

    Thank you

    Ralph8688.log.zip

     

  • 0 in reply to RH2248
    TI__Genius 9175 points

    Hi Ralph,

    Your problem seems to be related to file-permissions. It looks like your CCS is installed into a read-only location. Normally, Eclipse is designed to work without problems in such environment. Aside from the workspace, Eclipse needs a writeable "configuration" area. This "configuration" area is, by default, the ccsv7/eclipse/configuration/ directory. If that directory is not writeable, Eclipse should automatically create a user-specific writeable directory somewhere in the user's "home" directory.

    I know that the above works seamlessly on Linux, but it doesn't seem to be working on Windows.  I'll try to find out why.

    In the mean-time, as you've already found out, you can manually point Eclipse to a writeable configuration directory using the "-Dosgi.configuration.area=@user.home/ccsv7_config" flag.  You've already added this flag into ccstudio.ini file - that allows you to launch CCS IDE.  And to make your headless commands work, you'd need to also add the same flag to the eclipse.ini file as well - headless commands are launched using eclipsec.exe, which uses eclipse.ini.

    Also, to keep your manual tweaks down to a minimum, i would remove the "-Dosgi.locking=none" flag, and maybe also roll back the permissions change you've made to the .fileTableLock file.

    - Baltasar

  • 0 in reply to Baltasar Belyavsky
    Intellectual 290 points

    Hi Baltasar,

    that was the missing tip!

    And for me, this solution is good enough :-)

    However, a CCS7 running out-of-the-box would of cource be nice... 

    Thank you

    Ralph