• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 54 subscribers
  • Views 764 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.

What might cause Makefile generation to fail?

Malcolm Hannah
Prodigy 20 points
Other Parts Discussed in Thread: CC1310, CCSTUDIO

I imported the rfPacketRx_CC1310_LAUNCHXL_tirtos_ccs example project into a new workspace, made some changes, then created a second Build Configuration (just a copy of the default Debug configuration).

The original configuration builds OK but the new one doesn't build at all.  I discovered that the generated makefile is zero bytes long.

In the workspace's .metadata folder there is a .log file which reports a java null pointer exception and this trace:

at com.ti.ccstudio.project.core.internal.build.temp.GnuMakefileGenerator.calculateSecondaryOutputs(GnuMakefileGenerator.java:1883)
at com.ti.ccstudio.project.core.internal.build.temp.GnuMakefileGenerator.addTargets(GnuMakefileGenerator.java:1332)
at com.ti.ccstudio.project.core.internal.build.temp.GnuMakefileGenerator.populateTopMakefile(GnuMakefileGenerator.java:831)
at com.ti.ccstudio.project.core.internal.build.CCSMakefileGenerator.populateTopMakefile(CCSMakefileGenerator.java:453)
at com.ti.ccstudio.project.core.internal.build.temp.GnuMakefileGenerator.regenerateMakefiles(GnuMakefileGenerator.java:602)
at com.ti.ccstudio.project.core.internal.build.CCSMakefileGenerator.regenerateMakefiles(CCSMakefileGenerator.java:383)
at com.ti.ccstudio.project.core.internal.build.CCSMakefileGenerator.regenerateMakefiles(CCSMakefileGenerator.java:369)
at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.performMakefileGeneration(CommonBuilder.java:1008)

So it seems that "secondary outputs" are implicated.  (Perhaps by being non-existent?)

If anyone recognises this scenario and knows of potential causes/solutions, please let me know.

I suspect that my merging of the TI-RTOS project into the rfPacketRx project is relevant.

For reference, I'm using CCS 10.4 (but 10.3 had the same problem) and I see this behaviour on two different computers with several projects.

  • 0
    TI__Guru* 82601 points

    Hi Malcolm,

    Please close CCS, then check your projectspec file (examples\rtos\CC1310_LAUNCHXL\drivers\rfPacketRx\tirtos\ccs\rfPacketRx_CC1310_LAUNCHXL_tirtos_ccs.projectspec).

    Check that your new build config/buildprofile looks the same as the Debug configuration.

    Since you say you have merged the tirtos builds project, maybe you can do a build test after just the merge and check where this error originates?

    Cheers,

    Marie H.

  • 0 in reply to Marie H
    Prodigy 20 points

    Thank you very much for responding, Marie.

    I wasn't sure what to check in the projectspec file.

    When I compared the original and copied cconfiguration nodes in the .cproject XML file, I found the only difference was the name attribute value, as expected.  (I ignored the numeric suffixes on some of the other attribute values.)

    As you suggested, I tried a clean import of rfRxPacket, creating a new Build Configuration before and after merging the tirtos project.  They both worked OK.

    Since this implicated one (or more) of my other changes, I tried undoing them and found the culprit: the Arm Hex Utility (in the project Properties, Build section).

    When I disable the Arm Hex Utility, I can create a new Build Configuration which does generate a valid makefile.  I can then re-enable the Arm Hex Utility in the copied configuration's properties, and everything succeeds.

    I suppose the .hex file might be the "secondary output" (after the .out ELF file) which the stack trace hinted at...