• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 101 subscribers
  • Views 1886 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.

RTOS: Issue compiling IPC Examples for OMAP-L138

James McLaughlin
Expert 1090 points
Other Parts Discussed in Thread: OMAP-L138, SYSBIOS, OMAPL138

Tool/software: TI-RTOS

I am attempting to compile the basic MessageQ example for both the ARM and DSP side of the OMAP-L138.  I'm using an LCDK-L138 with CCS 7

I have tried lots of different combinations of SYS/BIOS, IPC and XDCTools.  I always seem to run into some kind of "unresolved symbol" error on the linker step, but it's different in each case.

I'll stick with the two combinations that seem to have gotten me closest.

Latest everything (as far as I can tell for this processor):

SYS/BIOS - 6.46.4.53

IPC - 1.25.3.15

XDCtools - 3.32.1.22_core

This gets me 5 "unresolved symbol" errors, all "ti_sdo_ipc_..." related (e.g. "unresolved symbol ti_sdo_ipc_gates_GateMPSupportNull_query__E").  This led me to this post: 

https://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/419641

which led me to attempt to rebuild the IPC libraries.  When I did this, I got this build error and couldn't get any further (probably worth a separate post, though):

"ti/sysbios/knl/Queue.xdc", line 183: unrecognized attribute (@DirectCall)
error: compilation of package.xdc failed: parser failed (pass 2)
gmake[1]: *** [package/package.xdc.inc] Error 1
xdctools_3_25_00_48\gmake.exe: *** [packages/ti/sdo/ipc/,.interfaces] Error 2
gmake: *** [all] Error 2

Recommended versions according to my IPC version (listed here: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/

unresolved symbol IND_CALL, first referenced in C:\ti\xdctools_3_24_05_48\packages\ti\targets\arm\rtsarm\lib\auto_init.ae9<auto_init.oe9>

  • 0
    Expert 1090 points

    Seems to have cut off the rest of the post and lost it, I'll recreate:

    Recommended versions according to my IPC version (listed here)

    SYS/BIOS - 6.34.04.22

    IPC - 1.25.3.15

    XDCtools - 3.24.05.48

    This gets me the error: unresolved symbol IND_CALL, first referenced in C:\ti\xdctools_3_24_05_48\packages\ti\targets\arm\rtsarm\lib\auto_init.ae9<auto_init.oe9>

    So my questions:

    - Is there a combination of library versions that make the MessageQ example work out of the box?

    - If not, what do I need to build/rebuild in order to get these to work?

    - Is there a recommended combination of versions that are the latest for working on this processor (if not the ones I listed above)?

    Thanks!

  • 0 in reply to James McLaughlin
    TI__Genius 12865 points
    Hi James,

    I'd suggest you stick to the versions recommended by the IPC release 1.25.3.15. If you look at 'IPC_Install_guide.pdf', it describes two ways of building the examples: one using CCSv4 (which is likely obsolete), and one using the command line outside CCS, in section C. Could you follow the latter instructions to build on the command line?

    Note that the executables built on the command line can still subsequently be loaded and debugged in CCS 7. Let us know if you are still encountering issues.

    Best regards,
    Vincent
  • 0 in reply to Vincent W.
    Expert 1090 points

    Thanks for the reply!

    Are the rebuild instructions in the IPC_Install_Guide.pdf different from the "Rebuilding IPC" section of the IPC_Users_Guide.pdf?  

    I followed those instructions to rebuild on the command line using gmake, which fails due to the error posted above:

    "ti/sysbios/knl/Queue.xdc", line 183: unrecognized attribute (@DirectCall)

    error: compilation of package.xdc failed: parser failed (pass 2)

    gmake[1]: *** [package/package.xdc.inc] Error 1

    xdctools_3_25_00_48\gmake.exe: *** [packages/ti/sdo/ipc/,.interfaces] Error 2

    gmake: *** [all] Error 2

  • 0 in reply to Vincent W.
    Expert 1090 points

    Ok wait, I see now.  This uses xdc instead of gmake.

    Are you referring to building the examples or "Rebuilding IPC modules"?

    The "multicore" example for the evmOMAPL138 seems to build fine (I at least get this output):

    generating interfaces for package ti.sdo.ipc.examples.multicore.evmOMAPL138 (because package/package.xdc.inc is older than package.xdc) ...
    all files complete.

    but I'm not sure what to do with the output files.  It seems to have added a "package" folder, package.mak file, and some empty files with "." at the beginning (supposed to be hidden linux folders?).  I should mention I'm on Windows 10

    For "Reuilding IPC modules", I get this:

    "ti/sdo/utils/NameServer.xdc", line 40: can't find imported unit: ti.sysbios.gates.GateSwi (ti.sysbios.gates.GateSwi)
    error: compilation of package.xdc failed: parser failed
    gmake.exe: *** [package/package.xdc.inc] Error 1

    Thanks again!

  • 0 in reply to James McLaughlin
    TI__Genius 12865 points
    Hi James,

    You normally do not need to rebuild the IPC modules/libraries as they come pre-built. To rebuild the examples (which I think is what you had in mind), follow the instructions in sections A and C in IPC_Install_Guide.pdf. Make sure you have made a copy of config.bld.default in <ipc_install>/ipc_1_24_xx_xx/packages/config.bld and modified rootDir to point to your code generation tools installation path. Given how little build output you got, it probably did not build anything due to some paths missing.

    Also you must set the XDCPATH environment variable as described in the guide.

    Best regards,
    Vincent
  • 0 in reply to Vincent W.
    Expert 1090 points
    Hmm, ok, I think I see what you're saying. But why would the xdc build not give me an error output if there were pieces missing?

    Also, to clarify, I'm referring to the examples available when you create a new project in CCS v7:
    - Project
    - New CCS Project
    - IPC Examples
    - OMAPL138 Examples
    - OMAPL138: MessageQ (ARM) (but also DSP version)

    I'm not really interested in building all my code on the command line, unless using "xdc" on the command line will prove that my installation is correct as a first troubleshooting step, or something?

    Thanks again
  • 0 in reply to James McLaughlin
    Expert 1090 points
    Progress on my original CCS project. Using the older SYS/BIOS and XDCtools listed above with the DSP project compiles successfully.

    Now I'm just left with the IND_CALL symbol error for the ARM version. I found this post:
    e2e.ti.com/.../305465
    which indicates someone had the same issue a few years ago.

    The recommended fix is to use compiler tools version 5.0.x , but I have 16.9.0.LTS. I'm trying to install and use the older 5.0.x version, but it won't let me select them (CCS shows as installed but I can't find them anywhere on the system and cannot select them as the Compiler Version in my project settings).
  • 0 in reply to James McLaughlin
    TI__Genius 12865 points
    Hi James,

    I was suggesting to use the command line to build to eliminate CCS as a variable, as the IPC release you are using is quite old and was never tested against the latest CCS.

    In any event, these threads seem to indicate you may need to upgrade to XDCtools 3.25.3.72 to workaround the issue with respect to IND_CALL:
    e2e.ti.com/.../305465
    e2e.ti.com/.../360045

    See if that helps.

    Best regards,
    Vincent
  • 0 in reply to Vincent W.
    Expert 1090 points

    Ok, that makes sense, just wanted to be clear.

    Thank you, the combination of versions in the second link worked for both the ARM and DSP versions of the project.  We will continue to develop using these.

    I'm new to developing using libraries like this, is this kind of build complication common?  

    If we were perhaps on a newer processor, would we have similar issues?

    Does this indicate this processor is reaching its end of life?

    Thanks again!

  • 0 in reply to James McLaughlin
    TI__Genius 12865 points

    Hi James,

    Glad to hear you got it working!

    To answer your questions, I can't speak to the lifetime of the device, as I am simply a TI-RTOS engineer supporting this forum. Probably better to ask on the device forum or other TI channels for a more official and accurate statement.

    What I can say is that there is no active development on the IPC 1.x stream, and that the release you are using is over 5 year old, hence the incompatibility with some of the latest components. With that in mind, it is best to stick to the component versions the release was tested on to avoid complications, and only upgrade as necessary as you did for bug fixes.

    Best regards,

    Vincent