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.

ROV usage with separate config project

Other Parts Discussed in Thread: SYSBIOS

Dear TI,

I think this is the correct forum for my post. I am building a library and I am testing using a unit test project.

I have created a new project (library) from the option provided in SYS/BIOS-typical (with separate config file)

I have created a new project (executable) from the option provided in SYS/BIOS-typical (with separate config file)

I have modified in both the library and the executable the build dependency to pint to the common configuration project. My common configuration project uses the sys bios and the path and version of the XDC is clearly defined!

All builds, all runs and all seems ok until, from my executable that is calling my library, I am trying to display the ROV.

I have this message that keeps popping up and do not manage to resolve it...

"XDC path and XDC tool location not set" => set project global RTSC preferences and relaunch ROV.

When I tried to do that, I am always getting to the project where nothing is defined (since the project uses a common configuration project)

Can you help?

Aymeric

  • Dear Support,

    Is someone looking into this problem? I am trying to debug heap, message queues in a muti thread environment and even a work around would be appreciated.

    Aymeric

  • Yes, I am going to try to reproduce the issue.  Could you please let me know which version of BIOS and XDCTOOLS you are using?

    Judah

  • I created a new project executable with a separate config file.  Build/Load, open ROV and everything is working fine.

    Maybe post some screen shots of the error?

    Judah

  • hey Judah,

    This is strange..

    So in my case, my config project uses bios and ipc

    My executable links to my library and let's say call function init_library (in property,build, dependency there is a reference project to the config project)

    My library uses contain the function init_library (in property,build, dependency there is a reference project to the config project) 6646.target_queue_manager.c

    Then when I get to the function, ROV is not available. Does it happen to you as well

    Aymeric

  • Can you post a screenshot to here?  I'm not understanding what you are saying.

    Judah

  • Judah,

    Sorry for not being that clear. I do not have a problem sending a screen shot but I am not sure what screen shot you want.

    So I am attaching a zip file with a lot of screen shots.

    I will try to make myself more clear.

    1) I have a library and a an example. I want both of them to be an RTSC modules that are sharing the same configuration file

    2) when I create a CCS project (LIBRARY OR EXECUTALE) using option "typical (with separate config project), CCS creates a third project which holds the RTSC configuration. See project_configuration_window.bmp and project_configuration_xdctools.bmp

    3) When I look at the example project or the library project, there are no RTSC information within the project itself (see:general_window_lib.bmp). Instead, I must configure the poject to have a dependency to the configuration project (see build_window_lib.bmp)

    So the order I did execute these steps were:

    1) create library and configuration_lib (new CSS project of type library)

    2) create example and configuration_example (new CSS project of type executable)

    3) Delete configuration_example project (I have no need for it) and instead modify example to have a dependency to the same configuration project as the library

    I hope I was clear up to now. because now I want to explain what I see after these steps:

    1) In either the library or the example, when I include a bios module (#include <ti/sysbios/knl/Task.h>), there is a question mark notifying an unresolved inclusion (see project_explorer_view)

    2) Even though there is this question mark, it is compiling, linking and running. However when I launch the ROV, I got this message (see rov_error)

    From what I can see the xdctools path are correct in the configuration project. I have tried to reimport all three components that I have talked about and nothing helps.

    Thanks for your help

    Aymeric

  • Have you specified the products in the global preferences?  Can you please do so if you have not in CCS.

    1.  Window->Preferences
    2.  Code Composer Studio->RTSC
    3.  Select the BIOS, IPC, XDCtools version just like your project
    4.  Hit "OK" and relaunch ROV.

    Judah

     

     

  • Thanks Judah, this was the answer.

    the message is confusing, My understanding from this message was that I has to set the XDC that I was using.

    I did not think I had to see all the modules that I was using in my current project.

    Thanks so much

    PS: Since I have the answer for my investigation, I will be able to ask about my second problem in another thread

  • Judah,

    I know that I have validated your answer regarding the ROV but I still have a wonder regarding the successful inclusions of headers.

    Usually, when the configuration and the executable are in a single project, XDC define the path to all the packages I would like to use (see images I sent before). This does not seem to happen when separating the 2 projects...

    From my project view, including headers from the RTSC modules I want to use:

    1) the BIOS (ex: #include <ti/sysbios/heaps/HeapBuf.h>)

    2) the IPC(ex: #include <ti/ipc/MessageQ.h>)

    are preceded with a question mark indicating an unresolved inclusion.

    I can force the question mark to disappear by adding a path in the include directories ("${BIOS_CG_ROOT}/packages" or "${IPC_CG_ROOT}/packages") but I am not sure it is correct. Is it?

    Aymeric

  • Ideally, CCS would automatically add include directories from the project's compiler options into the search paths used by the editor.

    This issue has come up in several internal-conducted CCS usability sessions and I believe it has been corrected in newer CCS releases.

    Your workaround is the correct approach to resolving the annoyance in the meantime.

    Alan