CCSv4 and LogicPD's EVM board

The instructions are for CCS 3.3 I believe.

If you are trying to build the examples, you can try importing the CCS 3.3 pjt into CCSv4. However I gave it a try and it was a pain as the migration didn't go so great. A bunch of paths got combined with some garbage so i had to manually clean it up in the Build Properties before I can get it to build correctly. Also the *.cmd file has a relative path to the  BSL library, you'll need to fix that also.

I'll file a bug against the import to see if I can get that addressed.

ki

Thanks Ki. You're showing me that at least I'm not losing my mind! 

I followed that link, and tried the migration instructions.  You're right, it got ugly pretty fast. And I have no confidence in my corrections to it.  I'll sit tight for the weekend, and wait for your instructions.

Thanks again.

Hi Walter,

I filed a bug for the issue. The bug number to track it is: SDSCM00035258. If you look at the bug, the workaround information is there.

Thanks

ki

Ki,

Thanks for reporting the bug number.  I looked at the info there, and compared it with my CCS setup, then I had an insight.

After I imported the example software from LogicPD, CCSv4 made the following complaint (and noted it in a file called "migration.log"):

!WARNING: Reference to an undefined user-macro detected: 'ProjectDir'. Please import the 'macro.ini' file after migration completes (File > Import > Managed Build Macros), or define the missing macro manually (Window > Preferences > C/C++ > Managed Build > Macros).

It mentions the "macro.ini" file, so I looked at that, and here is the all it contains:

EXT_ROOT__evmomapl138_bsl = ../../

This appears to be a macro that replaces "EXT_ROOT__evmomapl138_bsl" with whatever comes after the equal sign (in this case "../../").  That looks really similar to what they mention in the bug workaround.

So I followed the instructions given above (to import the 'macro.ini' file after the migration completes), and it seemed to do something.  It may have even cured that problem for all I know. (Though I'm not sure. Because I'm still a bit lost.) 

Perhaps someone has insight on what to do next.

Walter,

You mentioned something very interesting about 'ProjectDir' being undefined. When I looked at the pjt files in the examples, they are all indeed undefined. This variable should contain the current path to the pjt. My guess is that the pjt files are generated by LogicPD and since the location of the pjt file will vary according to the user, they left it blank. This is ok for CCS 3.3 because CCS 3.3 will figure out where the pjt file being opened is, and set the variable value accordingly.  But when doing the import to v4 before ever opening the pjt file in 3.3 will cause an issue because v4 counts on there being a valid path for 'ProjectDir'.

So the workaround is:

Open the pjt file in your text editor and modify line 4 (where ProjectDir) is defined to either:

• Path to the location of the project file.. OR
• Use the $(Proj_dir) macro  (CCSv4 will know what to do with this macro on import)

The latter is easier

ex:

ProjectDir="$(Proj_dir)"

The save the pjt file and import it into v4. The wacky paths will be no longer though don't forget to fix your cmd file to point to the correct location of the bsl library).

Thanks

ki

Ki,

I believe your suggestions (listed below) worked!  At least I'm not getting the previous error messages. Instead, I'm getting a new error message that arises further along in the build process.

C:\Program Files\Texas Instruments\ccsv4\utils\gmake\gmake -k all

subdir.mk:35: *** target pattern contains no `%'. Stop.

Any clues on what that is?

==================================

==================================

Open the .pjt file in your text editor and change this:

ProjectDir=""

To this::

ProjectDir="$(Proj_dir)"

Also, use your text editor on the linker_dsp.cmd to change this:

-l ..\..\..\..\bsl\lib\evmomapl138_bsl.lib

To this:

-l <dir_pathname>\bsl\lib\evmomapl138_bsl.lib

where <dir_pathname> is completes the full pathname for this library file

Walter Snafu said:

I believe your suggestions (listed below) worked!  At least I'm not getting the previous error messages. Instead, I'm getting a new error message that arises further along in the build process.

C:\Program Files\Texas Instruments\ccsv4\utils\gmake\gmake -k all

 

subdir.mk:35: *** target pattern contains no `%'. Stop.

Any clues on what that is?

Actually, this was the exact error I was originally getting (because of invalid paths). And editing the pjt file manually (ProjectDir="$(Proj_dir)") and re-importing fixed this. I assumed this was your original error too. I'm surprised you got this after modifying the pjt file.

Could you attach the example folder. I would like to see what the imported v4 project files look like. Just zip up and attached everything in:

.\evmomapl138_v1\tests\evm\<example>

Thanks

ki

Walter,

You may want to delete the existing project and re-import. Actually the safest thing to do is to delete from your workspace and also delete the whole unzipped logic PD drop and unzip again.

ki

5672.lcd_char.zip

Attached the file.

yes you have the mangled paths that I saw. I also noticed that you did not update the "test_lcd_char.pjt" file so that would explain the errors. Could you use the attached pjt file and re-import into CCSv4?

Thanks

ki

Ki,

I deleted the old files and unzipped anew.  I downloaded your .jpt file, and imported it. The a build produces this error from the linker:

'Invoking: Linker'

"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/c6000/bin/cl6x" -@ccsLinker.opt -o "C:/CCStudio_v3.3/boards/evmomapl138_v1/tests/evm/lcd_char/ccs/evmomapl138_test_lcd_char.out"

Almost there! In your linker_dsp.cmd file, you need to specify the library itself, not just the path (line 8)

-l C:\CCStudio_v3.3\boards\evmomapl138_v1\bsl\lib\evmomapl138_bsl.lib

ki

Ki,

I'm confused, because my linker_dsp_.cmd file already had the full path specified (complete with filename), exactly as you have above.

Also, CCSv4 is calling out a different kind of error.  Here it is again (complete with weird line-breaks):

'Invoking: Linker'

"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/c6000/bin/cl6x" -@ccsLinker.opt -o "C:/CCStudio_v3.3/boards/evmomapl138_v1/tests/evm/lcd_char/ccs/evmomapl138_test_lcd_char.out"

"C:\DOCUME~1\A21YWZZ\LOCALS~1\Temp\053123", line 14: fatal error: unrecognized

file:

"C:/CCStudio_v3.3/boards/evmomapl138_v1/tests/evm/lcd_char/ccs/linker_dsp.cm

d"

I could understand a "can't find file", but it's calling out "unrecognized file".  What on earth is that?  It's claiming the linker_dsp_cmd file is "unrecognized".  ??? But I can clearly see the file myself, and it looks okay.  So I'm confused.

Sorry for the confusion. In the zip file you attached, the linker command file did not have the file name specified, only the path. You must have updated it since.

Otherwise I had no build errors. Let me try a few other things.

One question - where do you have your workspace (what is the path)?

Thanks

ki

The default workspace (setup by CCSv4) was

C:\Documents and Settings\<privatename>\My Documents\workspace

I changed it to:

C:\Documents and Settings\<privatename>\My Documents\TI workspace

I presumed it wouldn't make a difference, especially since CCSv4 gave me the option to change it.

TimHarron,

I'll try and merge-in my dim understanding of things. 

The problem you discuss:

CCSv4 build generates error - target pattern contains no `%'. Stop.

I read your wiki page and looked deep within my CCSv4 at the things you discussed.  It seems that in each case, the problem centers on the definition (or mis-definition) of the parameter EXT_ROOT.  When I look under Project>Properties>Macros, that parameter is undefined. (Somewhere something is defining it.) Your solution, if I understand it right, is to explicitly correct for the mis-definition of EXT_ROOT.  That seems to be the effect anyway. 

I believe Ki-Soo solved that problem in an easier, cleaner way -- a way that is easy to use when importing any CCSv3 project. That is, before importing the project, edit the .pjt file entry for ProjectDir, like this:

ProjectDir="$(Proj_dir)"

Let me mention something else curious.  When importing a CCSv3 project into CCSv4, it creates a migration.log file, which intructs you to import a "Managed Build Macro" file named "macros.ini" When you look within that macro.ini file, it contains only one thing:

EXT_ROOT__test_lcd_char = ../../

Here again is that mysterious reference to EXT_ROOT.  It appears to me that those instructions were TRYING to correct this problem.  Perhaps a proper implementation of the macros.ini file would be a better/cleaner solution?  I dunno.  But it is suggestive.

Walter,

Thank you for the feedback.

Ki's suggestion is indeed probably an easier/better way to do it, but as that is not how I fixed my project that is not how I created the article. I think I may edit it with an alternate answer as that would probably make things far easier to migrate. In either case, this problem has already been filed as a bug so hopefully future revisions of the import wizard will make conversion easier for us all.

yes the issue on Tim's article is the same discussed in this thread. Either option will work, though with Tim's workaround you can use it to fix the issue for a project already imported.

Walter - I'm still at a loss on why you are getting that linker issue. I have the project and workspace in the same location as you. The only difference is that I installed CCS in a different location, but that should not matter. One other thing to try is to set your TEMP directories to a path without spaces. I have seen some build issues in the past because of that.

I attached my project if you want to take a look and import it.

Walter, 

Regarding macros.ini files. CCS v3.3 has a macros.ini file as well. CCS v4 import wizard looks at .pjt file and if it finds a macro that it does not know about (i.e. not a system pre-defined macro), then it will print the message in migration.log, assuming that user has added a user defined macro in CCS v3.3. macros.ini. This file is usually in ccs v3.3 cc\bin directory. Some projects that I have seen in the past used this feature to refer to 3rd party software that existed outside of project source tree. However, folks distributing these types of project usually made sure to also distribute macros.ini file for CCSv3.3 that user then adjusted... or provided information on how to create this macros.ini file.

macros.ini file that is part of a ccsv4 projects serves a similar purpose, but it is used as a mechanism to handle relative path information when importing CCS v3.3 projects. It is also used to make CCSv4 created projects portable. Eclipse and hence CCS does not handle relative paths in project information(that go outside of immediate project directory) and hence the addition of macros.ini file. In summary, migration.log is referring to the fact that there was some macro in .pjt file that it did not know how to resolve. It is unrelated to macros.ini file that was generated by CCSv4 during project import. 

Martin

Ki,

When I try to import your file, I run up against a wall.  That is, if I import it as a legacy CCSv3 project, it complains that "metadata" files are present and must be deleted.  However, if I import it as an existing CCSv4 project, it cannot locate any project to import.

I'm afraid I'm headed for the dunce award of the day, but I need a further hint.

hmmm... It should be able to be imported as an existing v4 project. You should just be able to specify the root location of that zip. But you may want to remove your existing project from the workspace.

Before you do that, did you try resetting your TEMP and TMP directories and rebuilding?

Ki,

When I look under Window>Preferences>C/C++>Make>Managed Build>Environment the two parameters you mentioned are already defined without spaces.

TEMP        C:\Docume~1\<privatename>\LOCALS~1\Temp

TMP           C:\Docume~1\<privatename>\LOCALS~1\Temp

I can't find where the workspace directory is defined.

-- Walter

Walter could you double check that this project does not already exist in your workspace? You would need to delete it from the workspace, there should be a dialog asking you whether you want to just delete project from the workspace (does not affect the project itself) or whether to delete all project files as well. Choose the option to delete just the project from workspace. A project that already exists in a workspace can't be imported a second time... unfortunately, there is no indication in import dialog that project was found but can't be imported. If you want to re-import 3.3 .pjt file, then you would need to go to directory where your project is and delete files/directories that begin with '.' (e.g. ".project", ".cdtbuild") 

Martin

I got the exact same problem (unrecognized file) when using notepad to edit the linker_dsp.cmd file.

I was able to solve it by using CCSv4 to edit the file. It turned out that notepad by default saved the file in UTF-8 and added a 'byte order mark' (EF BB BF).

Ki and peter_ne,

A major step forward.  I was eventually able to download (see below) Ki's version of the project file, then build and run.  And it worked!  (My first successful build of an EVM specific program!)

peter_ne gives an accurate clue.  (Indeed I used the notepad editor to edit the linker_dsp.cmd file.) Peter_ne's explanation also makes sense -- the notepad editor creates files that have some difference that is invisible to the eye, but bothers CCSv4.  (If true, then this would encourage a bug fix for CCSv4.)

I will try re-importing the LogicPD program from scratch (using the CCSv4 editor instead of the notepad editor, and using Ki's nifty fix (ProjectDir="$(Proj_dir)").  I'll report back on how that works.

======

Note FYI;  I had a bit of trouble importing Ki's project.  His project came in zip format, so I unzipped it, and tried to import it.  For some reason CCSv4 would not proceed. The import menu has several choices that seemed appropriate, but didn't work:

Legacy CCSv3.3 Project

Existing CCS/CCE Eclipse Project

C/C++ Executable

Existing Projects into Workspace

None of those worked. (The import wizard just waited for me to 'select' which project to import, but the wizard did not display any projects to select. The wizard just sat there waiting for me to select something that wasn't selectable. A dead end.)

Nothing worked.  I was about to give up.  I eventually tried importing it as an "Archive File", without unzipping it first.  This is what worked. 

The import process wasn't obvious to me, and took quite a while to figure out. (I dunno. Perhaps I'm a dunce.)

Ki and peter_ne,

I tried the fix given by peter_ne, but it didn't work for me. 

That is, I deleted all my projects (and their metadata files), and proceeded from a clean starting point. I didn't use the notepad editor.  Instead I used the CCSv4 editor to update the project file (ProjectDir="$(Proj_dir)"), and the linker_dsp.cmd file.  Followed by import and build.  I get the same linker error as before -- "unrecognized file".

This is weird.  Ki's project built without and ran error on my system.  But not the same LogicPD file I fixed and imported. This is mysterious.

Walter,

You may want to delete the project from the workspace and also try a workspace clean (set everything to a default state) and reimport.

ki

What do you see if you compare Ki's linker_cmd.dsp and yours? Use a tool like windiff, a visual inspection is not good enough.

If you proceed in a structured way you should be able to find out what is going on. The following worked for me (by head so I hope I did not skip something):

(1) Copy the linker_dsp.cmd to a temporary directory, so later you can figure out what went wrong

(2) Delete the whole directory structure with the 1014013A_OMAP-L138_GEL_BSL_Files

(3) Unzip them again

(4) Open the project file with CCSv4 and set ProjectDir="$(Proj_dir)". Save the changes.

(5) Import as 'Legacy CCSv3.3 Project'.

(6) Use a tool to compare the linker_dsp.cmd file with the file you stowed away in step 1. Use something like windiff and/or a binary editor. Only the line refering to evmomapl138_bsl.lib should differ, else you know what was wrong. Do not compare the files visually with notepad or CCSv4 since that does not tell you much.

(7) Reapply the change to the linker_cmd.dsp using CCSv4. Save the file.

No need to change TMP or TEMP environment variables. The system handle's pathnames that are not conform the old dos 8+3 standard successfully (the domain name part in your user directory, after the '.' is > 3 characters).

Hope this helps,

Peter

I did the follow experiment twice. 

I deleted all projects, all metadata, and cleaned the workspace -- to start with a clean system.  Then I imported the legacy v3.3 files from LogicPD.  And used a linker_dsp.cmd file I got from LogicPD and modified -- using the CCSv4 editor -- to use the proper library path.  On a build, it failed and gave the Linker error I mentioned previously.

Then I did it all again, only this time I replaced my linker_dsp.cmd file with the one I unzipped from Ki.  This time it worked!  The ONLY difference was the linker_dsp.cmd file!

So peter_ne must be correct that the linker_dsp.cmd file is the culprit.  Yet, I created the failed version of the file using the CCSv4 editor! One would think CCSv4 could read its own files!

At this point, I've tried using the CCSv4 editor, and the MS Notepad editor -- and both files failed to be recognized by CCSv4.  So what editor am I supposed to use?  How did Ki create his file that worked?

Walter,

I use PSPad as my editor. But many people use the v4 editor without issue. Can you attach your linker command fine again? I want to do a diff

ki

Ki,

Here is my linker_dsp.cmd file.  It is three bytes larger than your file, but the differences are invisible to the eye (in the CCSv4 editor and MS Notepad).

[P.S.  The "Insert Media" command does not appear to be working.  I've tried uploading my file five times now, and it doesn't seem to show up.  What's up?]

Hit the Options link and use the File Attachment option to upload the file

Did the file upload yet?

Yup. Got it. I did a diff using a diff tool and the tool said that my cmd and your is different. But when the diff tool then opened up both files side-by-side, the files looked identical. I even enabled display of special characters and still the same. But dropping in your file in my folder, i got the same linker error. So I open your cmd file again in my editor and used the built it DOS format conversion tool and saved the file. The errors went away.

I don't know how that cmd file was some format besides DOS (Unix? Mac?). Do you use another machine besides PC? Maybe you have some setting for defualt file format and it is not DOS?

I'm using a PC Windows XP.  Nothing unual.  Not Linux, Unix, or Mac.

Very strange symptoms on this problem. 

So I tried another experiment.  I took Ki's linker_dsp.cmd file into my CCSv4 editor, made some insignificant change, saved it, and it re-built fine.

I did did the same using the MS Notepad editor, it re-built fine.

Whatever was weird in that file, it was both invisible and unaffected by these editors.  That is, once the weirdness got into the file, these editors neither displayed it, detected it, nor fixed it.  The editors simply pass along the weirdness to any daughter file, like some kind of genetic defect.   

I don't know how the weirdness got into that file. So far, we can't even tell what the weirdness is -- except by the fact that it causes the linker failure.  It's like a new kind of computer parasite that we don't know how to detect. We just know it is within some files, and not others -- and editors don't eliminate it. 

Meantime, I just copied Ki's version of the file into all the many directories where it is needed. So at least I have a working system now.

Very strange.  I'm curious what the explanation finally is. Let me know how it turns out.

Thanks for all your help!!!

Use a binary editor to spot the differences. I am sure that if you use notepad to save the file in Ascii encoding everything is fine as well. Maybe the copyright sign (which is not ascii) triggers the editors to save it in one of the unicode formats with a byte order mark. The linker cannot make sense of this. Maybe TI (am am new to the platform but assume the linker is TI's) could update the linker so it handles this AND DOS/Unix line-ending?

Peter

I can spot the difference with a binary editor. Thee characters in the beginning of Walter's cmd file that does not exist in mine.

Mine:

Walter's:

The original file from Logic PD does not have those extra characters either. Somehow, someway those characters got added when Walter modified the cmd file....

strange!

Ki-Soo Lee said:

The original file from Logic PD does not have those extra characters either. Somehow, someway those characters got added when Walter modified the cmd file....

strange!

Actually not so strange:

http://en.wikipedia.org/wiki/Byte_order_mark#Unwanted_BOMs

http://www.howtofixcomputers.com/forums/windows-xp/extra-characters-beginning-file-ef-bb-bf-263070.html

For grins, I opened my working cmd file in notepad and save the file (without doing anything). I noticed that those extra characters got added! And the of course the build failed. When I removed them, all was fine again.

But I then tried the same with some other project's cmd file I had laying around and saving in notepad did not do anything. I really don't have an explanation for this.

Walter Snafu said:

• Edit the .pjt file from LogicPD, change the ProjectDir line to:  ProjectDir="$(Proj_dir)"

FYI - CCS 4.1.1 (which was released yesterday) has a fix where the above step is no longer necessary.

Ki-Soo Lee said:

For grins, I opened my working cmd file in notepad and save the file (without doing anything). I noticed that those extra characters got added! And the of course the build failed. When I removed them, all was fine again.

But I then tried the same with some other project's cmd file I had laying around and saving in notepad did not do anything. I really don't have an explanation for this.

Ki,

Perhaps the "other project's cmd file" didn't have non-ASCII characters in it.  ???  The files we've been dealing with (from LogicPD) had at least two non-ASCII characters (or extended-ASCII characters?)  The copyright symbol, and the character before that (which is some type of foreign A symbol).

I suspect that when non-ASCII characters are in the file, then the editor needs some way of encoding those, and that requires more than 8 bits.  And then the issue of endian-ness enters into the mix, and the three bytes at the beginning of the files tell the editor if it's an out-of-order endian-ness.  I may not have the details of that right, but I think we're homing in on the cause:  Non-ASCII characters, combined with endian issues.