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.

Not having far data access model set caused Linker to stall

After adding some new code my project no longer finished linking. When building the project, and clicking on the "Details" button in the "Build Project" dialog box, I saw this status message (the build stalled at this point and I needed to cancel it):

"Refreshing workspace (Blocked: The user operation is waiting for background work to complete.)"

The line which I found was causing this problem was a line accessing a variable which was declared as:

File A:

far UInt32 foo = 0;

File B:

extern UInt32 foo;
foo = 0;   <-- Commenting out this line allowed the linking to finish.

To fix the problem I needed to set the CCS Build, C6000 Compiler, Runtime Model Options, Data access model (--mem_model:const) setting to "far".

I'm adding this post because the fix for the problem does not seem obviously related to the error symptom so this may save others some time.

I'm using CCS 5.1.0.09000, developing for the C674x DSP on the EVM DM816x.

Annie.

  • Annie,

    Is CCS hanging during the link step, and does it happen consistently each time you build? If so, could you do a quick check to see if the linker similarly hangs when linking on command line instead of through CCS. You could simply copy the command line output for the linker that you see in the CCS build console and invoke that from a command prompt. This can help isolate if it is a codegen tools issue or CCS issue.

    At that point we may need a reproducible test case. Are you able to send us a simple project that can be used to recreate the issue?

  • I have the same problem.  My build hangs when linking.   I tried the -far trick the first poster suggested and that worked for me too.  The strange thing is this project has been workiing then I made a few changes and now it constently will not link unitl I rebuilt with the -far option.   I turned verbose linkng on and that did not give any extra diagnostics.   By the way - I have not tested the code yet so I'm not sure if it works or not.

    The question is what impact does the far option have on my code? 

    I'm using CCS 5.2.1.00018 & DSP/Bios 5.41.13.42

  • I narrowed the problem down to a particular line of code:

    One class was externing another class like this:

    extern EtherData* etherData;

    I added a "far" like this:

    extern far EtherData* etherData;

    Now my code links without the  mem_model:data=far flag

    Why is this needed and why does the linking hang?

  • As Aarti suggests, we need a complete, reproducible test case to analyze this any further.

  • It's been 3 years, and the bug is still there. I'm using CCS 5.4 for the C6000. The linker would always hang (with 100% CPU-usage) until I changed mem_model:data to "far". Thanks to the original poster (Annie) for posting this work-around!
  • We still lack a test case which allows us to reproduce the behavior for ourselves.  That is the reason why we have no idea about the cause of the problem.  I'd appreciate if someone would send us a CCS project that has this problem.  

    Thanks and regards,

    -George

  • George, Your request is reasonable. It's too bad that those in the defense industry cannot give their code to you due to inability/hassle of getting approvals. That leaves the commercial world, and I suspect an NDA would be required before they'll let code out of the building. For you, all this is frustrating. I hope somebody is eventually able to give you something.

  • Roughly what size is this application? What's the size of the executable object file when you are able to link successfully? How long do you let it run before deciding it is hung?
  • The .out file of the release-build is about 2.5 MBytes. There are 228 .c files, with perhaps a couple of .cpp files in there. To get it all to fit, I put the less-urgent code and data in the SDRAM, and the remaining more-urgent stuff in the ISRAM. This is done using a SECTIONS directive in my lnk.cmd linker-command file specifying where each file goes. The build is entirely on the hard disk, so network-problems should not affect the build. I let the linker run for at least 20 minutes before deciding it's hung; with the work-around, linking takes around one minute.

    Mark