PWRM Linking Issue in CCSv3.3

What version of the compiler are you using?  A compiler upgrade may help.  In CCS select Help | Update Advisor | Check for Updates.  See http://tiexpressdsp.com/index.php/Compiler_Version_Numbers_and_What_They_Mean to understand what compiler version you should get.

I suspect a bug in the linker.  Even if you are doing something incorrect, the linker should not hang.  If this is the case, then we need to reproduce what you see.  Are you willing to send us the entire project?

Here's an idea that is easy to try but unlikely to work ... It may be that the linker is not truly hung, but is just taking a really long time.  It has happened to other customers.  In most of those cases, a process called type merging was the problem.  You can disable type merging with the linker switch -b.  It is worth a try here.  But, all things considered, I would be surprised if it worked out.

Thanks and regards,

-George

hello,

This may help - from BIOS 5.41.02.14 rel notes - "The new Power Manager (PWRM module) for C6748 devices optionally uses two packages (PMI and PSCL) for implementing low-level power control functionality.  When the PWRM module is enabled in your DSP/BIOS configuration, it will attempt to link to the libraries in these packages.  This requires that the paths to the PMI and PSCL libraries be included in the linker search path.  These paths are included by default in the CCSv3 project files for the DSP/BIOS examples for the evm6748 and evmOMAPL138 platforms.  If you are creating your own CCSv3 project files you should similarly include the following paths for the linker: -i"%BIOS_INSTALL_DIR%/packages/ti/pscl/lib" -i"%BIOS_INSTALL_DIR%/packages/ti/pmi/lib".  CCSv4 projects using PWRM will also require the user to add the libraries to the linker search path"

So basically BIOS in CCSv3.3 is automatically linking in these libs (check *cfg.cmd) - you just need to add the paths if using your own project.

I'd also advise you to move to this vers of BIOS - it has many fixes for PWRM. If/when you do then its recommended to use >= the version of Codegen that the BIOS was tested with (cgt 6.1.9).

BIOS rel notes are at http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/dspbios/5_41_02_14/exports/docs/Bios_5_41_02_14_release_notes.html

Cheers, Alan

First of all, thank you for posting a response. The compiler version I have appears to be 6.1.10 and when I go to the Update Advisor site it says my configuration is up to date. Unfortunately I am unable to send you the entire project but I could check into removing the proprietary portions to see if it would still happen then. I also did try the -b option but it did not seem to make a difference.  

What would you consider to be a really long time to link and still succeed? I've definitely let it link for 15 minutes or so before stopping the build.

Alan, thank you for your response as well. I am using 5.41.02.14. I did notice what you were mentioning. What I tried to do was both link directly to the folders with the libraries as you mentioned and pull the libraries directly into my project. Both actions seem to have the same effect. To be clear, if I enable PWRM and don't link in the files then I get unresolved symbols and the build fails that way instead. What it directly seems to relate to in my project is the "Scaling configuration library" I specify in the tcf file under the PWRM window. In other words, it doesn't matter if I link in pscl_cfg_evm6748.a674 or pscl_cfg_null.a674 and specify the library appropriately in the PWRM menu, linking will hang after that.

Please upgrade your compiler to the latest on the 6.1.x release stream, which is 6.1.13.  Go to http://tiexpressdsp.com/index.php/Compiler_Installation_and_Selection#CCStudio_3.x to see how to do it without using Update Advisor.  I can't promise this will fix your problem.  But you will pick up fixes to some linker bugs.

iceomas said:

What would you consider to be a really long time to link and still succeed? I've definitely let it link for 15 minutes or so before stopping the build.

I have heard of cases where folks got a successful link after 45 minutes.  Of course, no one thinks that is acceptable.  But, in your case, it might get you farther along than you are now.

iceomas said:

The compiler version I have appears to be 6.1.10

How did you come by v6.1.10?  You definitely want to avoid that release.  The compiler, not the linker, has a pretty severe performance bug.  The generated C6000 code can be pretty bad.

Thanks and regards,

-George

George-

I just upgraded my compiler to 7.0.1 and the linking is still hanging with that compiler. I will let it hang for about an hour to see if it ever finishes but that still leaves me with this issue as a whole. It's never easy, is it?

I'm not sure how I came by 6.1.10 but I didn't have any problems with it until now.

             -Thomas

Alright, after 30 or so minutes it finally finished with this error:

[Linking...] "C:\Program Files\Texas Instruments\C6000 Code Generation Tools 7.0.1\bin\cl6x" -@"Debug.lkf"
<Linking>
".\HWINTFC.h", line 263: warning: relocation type is static base-relative, but
   references symbol "_hEdma" defined in section ".far"; references to section
   ".far" are not relative to any static base, so this relocation cannot be
   performed (type = 'R_C60BASE' (80), file = "C:\\Documents and
   Settings\\thomas.price\\Desktop\\ConneryX02\\Debug\\HWINTFC.obj", offset =
   0x00000d04, section = ".text")
warning: output file "./Debug/ConneryX02.out" cannot be loaded and run on a
   target system

Once I removed the extern hEdma, it linked and built normally again. Do you know what this error means?

This looks like a "near" access to a "far" variable, most likely due to mixing levels of -ml.

I still think it is a bug that the linker takes 30 minutes to finish.  I'd appreciate if you could send us a test case.  Does the link run fast after you fix your source code?

Thanks and regards,

-George

The link does run fast now. At this point though I am seeing the issue where the system will go through initialization (I can set a breakpoint in the peripheral init for example) but then I don't seem to ever hit main. I've seen this issue a few times before and I think it may be another memory-related issue. Normally I just start from a stable baseline again and try to add one small new piece at a time until I can see it work again. I'm not quite sure though what causes the problem where you never hit main.

In any case, the original problem of the long linking is avoided now that I removed that issue. You will have to catch me outside of the message board to see my code. There are some proprietary items in it that I will want to clean out before giving you anything.