• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 1633 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.

AM335x StarterWare Include Paths Broken

Victor Wheeler61
Expert 2215 points
Other Parts Discussed in Thread: AM3358

Hello!


I have the TI AM3358 Starter Kit, and installed AM335x StarterWare using

    AM335X_StarterWare_02_00_01_01_Setup.exe


and left the installation root as the default:   C:\ti\AM335X_StarterWare_02_00_01_01


In CCS  v6.1.2.00015  I set my workspace to E:\Dev\Clients\xxxx\project_name\fw\

Then I imported the examples I wanted to try, and the DRIVERS, SYSTEM and PLATFORM library projects, and left the configuration as "DEBUG".  I selected both checkboxes at the bottom when importing:  A) Automatically import referenced projects found in same search-directory, and B) Copy projects into workspace.

First, knowing that I need the DEBUG versions of the DRIVERS, PLATFORM, etc. libraries, I started with DRIVERS.  Let's take that as an example.

In the DRIVERS library project, the device is set to "Generic CortexA8 Device" and the compiler i is set to TI v5.0.4 [ TI v5.2.6] (I didn't change these and assume this means that compiler TI v5.2.6 is being substituted).  When I attempt to build the DRIVERS library project from my imported project, I get errors like this:

**** Build of configuration Debug for project drivers ****

"C:\\ti\\ccsv6\\utils\\bin\\gmake" -k -j 4 -s cppi41dma.obj
'Building file: C:/ti/AM335X_StarterWare_02_00_01_01/drivers/cppi41dma.c'
'Invoking: ARM Compiler'
"C:/ti/AM335X_StarterWare_02_00_01_01/drivers/cppi41dma.c", line 43: fatal error: cannot open source file "hw_types.h"
1 catastrophic error detected in the compilation of "C:/ti/AM335X_StarterWare_02_00_01_01/drivers/cppi41dma.c".
Compilation terminated.


Obviously, the INCLUDE paths should include this, since the  hw_types.h  file is -- in fact -- in the

C:\ti\AM335X_StarterWare_02_00_01_01\include\hw\

directory.

On close examination, the project already contains a set of INCLUDE directories that appear to be COMPLETE except for the pathing:  specifically, "drivers" Project > Properties > Include Options lists the following include directory (as well as 5 others):

"${ORIGINAL_PROJECT_ROOT}/../../../../../../include/hw"

and the ORIGINAL_PROJECT_ROOT variable is listed in "drivers" Project > Resources > Linked Resources as having this value:

C:\ti\AM335X_StarterWare_02_00_01_01\build\armv7a\cgt_ccs\am335x\drivers

which is correct (it is a valid path and has the project files in it).  If you look carefully, the  "${ORIGINAL_PROJECT_ROOT}/../../../../../../include/hw"  path uses the ".." relative path 6 times, but if you count the directories up from the  ...\am335x\drivers\  directory, climbing to the parent directory 6 times winds up at

C:\ti\

but there is no

C:\ti\include\

directory!  The correct include directory (containing the needed files is here):

C:\ti\AM335X_StarterWare_02_00_01_01\include\

While this is quite simple (".." should be changed from 6 times in a row to only 5 times in a row), I do not think that manually editing all the INCLUDE directories in 15 or so projects is the correct answer.  Is this a bug in the AM335x StarterWare project include paths?  Or should I have installed it in a different way?  Or imported the projects in a different way?


Help!  :-)


Kind regards,

Vic

  • 0
    Expert 2215 points

    More notes:

    This seems to be a ubiquitous flaw in the AM335X StarterWare CCS .cproject files (at least in all the ones I have tried to build so far). In the INCLUDE directory list ONLY (not the target path or anything else), if "../../../../../../" is edited in the .cproject file to "../../../../../" (only 5 in a row instead of 6), then the examples build correctly. This is all about relative paths within the AM335X StarterWare installation directory, so I have to conclude it is a bug in the version of the StarterWare package I have.... The error is both in the DEBUG and RELEASE configurations.

  • 0
    Expert 2215 points
    More notes:

    And now I'm beginning to think that the build target paths should also be under

    C:\ti\AM335X_StarterWare_02_00_01_01\binary\armv7a\...

    instead of

    C:\ti\binary\armv7a\...

    Correct? (The .cproject files are sending the generated outputs to the latter....)
  • 0
    Expert 2215 points

    More notes:

    Further errors in the .cproject files for the non-library project echoUart (and likely the other non-library projects as well):

    For both the DEBUG and the RELEASE, the opening XML NODE <configuration artifactExtension="out" ... >

    requires several path corrections. The main problem seems to be that the paths assume that the project directory is in the original install directory (not taking into account the fact that the project may have been imported).

    So while the LINKER OUTPUT datum in the .cproject file indicates

    &quot;${ORIGINAL_PROJECT_ROOT}/../../../../../../../binary/armv7a/cgt_ccs/am335x/evmskAM335x/touchScreen/${ConfigName}/${ProjName}.out

    ...several post-link operations then use the following path (e.g. as an argument to the tiobj2bin.bat file):

    &quot;../../../../../../../binary/armv7a/cgt_ccs/am335x/evmskAM335x/touchScreen/${ConfigName}/${ProjName}.out

    and since the compile/link/post-link operations are occurring from outside the StarterWare install directory (in my case, on a completely different disk drive), the relative path above that is getting passed to the tiobj2bin.bat file is not even on the correct disk drive!

    There are about 4-5 of these where I had to insert ${ORIGINAL_PROJECT_ROOT}/ in front of the relative path to make it work. The most tricky is this one, because it additionally involves removing one of the ".." elements to make it go to the correct directory:

    Original string: &quot;$../../../../../../../tools/ti_image/tiimage.exe&quot;

    Corrected string: &quot;${ORIGINAL_PROJECT_ROOT}/../../../../../../tools/ti_image/tiimage.exe&quot;

    Unless I am missing something (I'm new to both TI processors and CCS), this is a really, really big mess. It looks like

    1) someone moved most of the projects UP a directory but forgot to fix all the relative paths in the .cproject files, and

    2) failed to account for CCS importing the project(s) to a possibly different drive.

    I now suspect even the output paths are incorrect (directly under C:\ti\binary\ instead of C:\ti\AM335X_StarterWare_02_00_01_01\binary\ ).

    Which would make the vast majority of paths in the .cproject files incorrect....

    So for the uartEcho project, having edited about 12-14 paths (all described above, both DEBUG and RELEASE configurations) in the .cproject file (I left the output target paths alone), I now finally have in

        C:\ti\binary\armv7a\cgt_ccs\am335x\evmskAM335x\uart\Debug\

    the following files:  uartEcho.bin, uartEcho.out, uartEcho_linkInfo.xml, and uartEcho_ti.bin.

    If the above are indeed bugs, I'm hoping a new (fixed) release of the StarterWare package is in the works soon....  If not, I'd sure like some guidance.

    Kind regards,
    Vic

  • 0 in reply to Victor Wheeler61
    Genius 5820 points

    How about using the community variantof StarterWare ( https://sourceforge.net/p/starterwarefree/code/ci/master/tree/ )? There I never have seen broken include pathes - and it comes with a lot of bugfixes that are missing in official release.

  • 0 in reply to qxc
    Expert 2215 points

    Hello, and thank you for the tip!  The bug fixes are wonderful to have.

    However, forgive me, but I am at a loss to understand how you have never run into broken path problems.  Specifically:

    I got a "snapshot" .ZIP file from SourceForge and installed the whole thing under 

         C:\ti\AM335X_StarterWareFree\

    preserving the entire directory structure below this (this was the first sub-folder in the .ZIP file containing all the rest:  bootloader\, build\, docs\, etc.).  So upon importing, the DRIVERS project, the symbol ORIGINAL_PROJECT_ROOT equates to

         C:\ti\AM335X_StarterWareFree\build\armv7a\cgt_ccs\am335x\drivers

    and in that particular project (DRIVERS), one of the include paths is this:

         "${ORIGINAL_PROJECT_ROOT}/../../../../../../include"

    which clearly navigates back up to

         C:\ti

    thus:

         C:\ti\include

    and I get compiler errors much the same as before, whereas if I remove one of those "..", it references the directory

         C:\ti\AM335X_StarterWareFree\include

    and it compiles correctly then.

    The output files seem to have a similar problem, referencing

         C:\ti\binary

    instead of

         C:\ti\AM335X_StarterWareFree\binary

    Would you concur?  Or did I miss something?


    Kind regards,

    Vic

  • 0 in reply to Victor Wheeler61
    Expert 2215 points

    I found the cause of the problem.

    When you execute (within CCS) File > Import > CCS Projects, select a project to import, and then DO NOT CHECK the "Copy projects into workspace" option, the relative paths within the project use a STARTING path that includes the ".\Debug\" or ".\Release\" directory created just below the project. Let's take the StarterWare "uartEcho" project for an example. In this case, when it is compiling, the DEFAULT DIRECTORY (in the Debug configuration) is:

    C:\ti\AM335X_StarterWareFree_02_00_01_01\build\armv7a\cgt_ccs\am335x\evmskAM335x\uart\Debug

    therefore, when the relative path to the INCLUDE directory is this:

    "../../../../../../../include"

    the actual directory being referenced is:

    C:\ti\AM335X_StarterWareFree_02_00_01_01\include

    as it should be, and the compile succeeds.

    HOWEVER!

    If you import the project AND CHECK the "Copy projects into workspace" option, the relative paths do not change, but the STARTING DIRECTORY does! Using the same project as an example, because you have copied the project into your own workspace, the DEFAULT DIRECTORY when compiling is in your own workspace (in my case, E:\Clients\xxx\etc.) instead of in the directory tree contained by the StarterWare installation directory. Thus, to compensate for this, CCS, when importing, alters the include paths to include a variable, like this:

    "${ORIGINAL_PROJECT_ROOT}/../../../../../../../include"

    and the value of ORIGINAL_PROJECT_ROOT is:

    C:\ti\AM335X_StarterWareFree_02_00_01_01\build\armv7a\cgt_ccs\am335x\evmskAM335x\uart

    as it should be. The problem is that this IS NOT THE SAME AS the default directory when the project HAS NOT been copied into the user's workspace! Thus, the referenced directory is instead

    C:\ti\include

    which directory does not exist! Thus, the compilation fails.

    I BELIEVE what CCS should have done instead is alter the include paths like this:

    "${ORIGINAL_PROJECT_ROOT}/Debug/../../../../../../../include"

    (while ensuring the Debug directory actually exists). Then it would compile correctly.

    Since it is not currently doing this (I'm using version: 6.1.2.00015), IF YOU CHECK the "Copy projects into workspace" option, you have to make anywhere from 10 to 25 path edits in the project to make it compile correctly.

    Until this is fixed in CCS, as long as I want to compile in my own workspace instead of in the StarterWare installation directory (the motive to check the "Copy projects into workspace" option), then I will have to be content to continue doing path edits (for each configuration [Debug/Release]) to get compiles done.