Post Go back to editing

Problem with importing VisualDSP++ project into CCES

Category: Software
Software Version:


After importing an old VDSP++ project into CCES and try to build project I got following error :

make: *** No rule to make target `../../Release/Power.dxe', needed by `..\..\Release\Power.ldr'.  Stop.

Project Import Report have two warnings : 

Non-standard location used for Debug output directory (outside of project folder)
Non-standard location used for Release output directory (outside of project folder)

How I can fix this error?

  • Hi,

    The "No Rule to Make Target" error can be a tricky one to track down, but it is ultimately caused by a reference in your makefile to a non existent file. The problem can be that it doesn't necessarily have to be an actual filename causing the problem; it could be a corrupt command line in the makefile.

    Can you please try perform a "Clean Project", available from right clicking on the project in the IDE and delete the dependency file (.d) from the debug folder and try rebuild the project.

    If this doesn't help, There is a limitation with path lengths on Windows.If you were to make your paths shorter, does the problem disappear?

    Secondly, The Warning occurred because, When importing a legacy project from a .dpj file, the contents of the .dpj file may specify that Debug and Release directories are located outside the project directory created by Andromeda.

    This means that once the project has been built and the user wants to debug the VisualDSP++ executable, the debug configuration wizard will not be able to locate the executable by searching under the project but will have to browse for it.So this warning is to inform the user that a non-standard location is being used for Debug/Release output directories and that the user will be responsible for browsing for the executables in subsequent wizards (such as the debug config wizard).

    So, please note that this will not cause any issue in your project.

    Please follow the below linked FAQ for more information on importing VDSP project into CCES.
    FAQ: Importing VisualDSP++ project files to CrossCore Embedded Studio

    Also, after importing the project go to Properties > C/C++ Build > Settings > Build Artifact and change the "Artifact name" to "${ProjName}".

    The import wizard creates a new directory structure, including new project files (.project and .cproject), reflecting the project options and build configurations from your VisualDSP++ project, and generating new startup code/LDF files.


  • Hi,

    Also, after importing the project go to Properties > C/C++ Build > Settings > Build Artifact and change the "Artifact name" to "${ProjName}".

    This was solution of my problem and now I am able to launch build. Thank you!

    But now I am facing another problem. During compilation of one of C source files I've got following error :

    [Error ea2004] "C:\Users\Username\AppData\Local\Temp\acc37e82b35000\acc37e82b35001.s":208 Illegal instruction. Value expression in bit instruction must be integer type and not symbolic.

    Previous errors prevent assembly

    Assembler totals: 1 error(s) and 0 warning(s)
    cc3089: fatal error: Assembler failed (code:1)

    I am not able to open this file as is temporary and removed immediately after build.

    OK. I found that is related to inline assembly instruction in C source file : 

    asm("bit clr mode1 CBUFEN;");

    Thank you,

    Radoslaw Kwiecien

  • So there is some problem with mixing ASM in C source file. When I use symbolic register MODE1 bit name in assembly instruction inlined in C file it is passed to intermediate assembly file but not recognized by the assembler.

  • Hi,
    The error message which you are encountering, ea2004, is an assembler error message which is produced for the general case of an instruction that cannot be encoded successfully.

    When using macros, such as CBUFEN, in asm statements, you need to ensure that the appropriate include files are made available to the Assembler when it processes the *.s file produced by the compiler. In this case, Can you please try to make "def<processor number>.h" available to the assembler as it defines the flag macros and let us know how it gets on. This can be done by adding the following:

    In example for  ADSP-21489 processor,

    asm("#include <def21489.h>");

    So, please add the appropriate processor number in the header and try.


  • Hi,

    Yes this fixed ea2004 error but I have to put this line in each C source file code with inline assembly which is not so convenient.

    I see there is no command line option for assembler to include specified file for whole project?

    Thank you,

    Radoslaw Kwiecien

  • The last one issue (I hope) : after successfully build all source files there are some linker errors about out of memory in output section with code (what I am able to understand as new compiler can generate larger code than the old one) but also in the section with data. We are using custom LDF file with some part of code and data in internal RAM areas and data placed into specified section will not fit into this section now.

  • Hi,

    Can you please let us know which processor you are using.


  • Hi,
    We understand that you are facing li1040 'out of memory error'. If so, we would first recommend ensuring two Linker Optimization options are enabled. The first is Linker Elimination, which can be enabled under CCES - Project->Properties->C/C++ Build->Settings->CrossCore SHARC Linker->Elimination->Eliminate Unused Objects

    The other is the option "Individually map functions and data items", which is found under the 'General' tab of the Link options (under this same tab) to "Generate Symbol Map"... When enabled, directs the linker to fill in fragmented memory with individual data objects that fit. When this option is selected, the default behavior of the linker (to place data blocks in consecutive memory addresses) is overridden.

    If you enabled the option to "Generate Symbol Map", the Linker will also generated a file which can be viewed in Internet Explorer to view a map of your project. It shows the memory sections declared in the LDF, their start and end bounds and - most importantly - their free/used space. Using this map file you can determine whether there is perhaps a memory section  that is being under-used that you could place more data into.

    Should you eventually exhaust the available internal memory, you would need to look at making use of SDRAM - if your target has external memory.Select Use external memory (SDRAM) to enable the size and partitioning controls under system.svc > Startupcode/LDF > LDF > External Memory

    Please refer the below CCES help path for more information about li1040 linker error:
    CrossCore® Embedded Studio 2.x.x > SHARC® Development Tools Documentation > Linker and Utilities Manual > Linker and Archiver Messages > Linker Messages > Errors > li1040

    Furthermore, we recommend the EngineerZone as a resource for Linker Errors such as this. We have assisted a number of customers with similar queries which can be found through the EngineerZone Search:

    If the above information does not helps, if possible can you please share us your example project along with the screenshot of the error that you are facing and also the steps to reproduce to replicate your issue. This will help us to assist you better.