AnsweredAssumed Answered

VDSP++ Project file keeps setting Loader:romsplitter parameter and failing to build .ldr

Question asked by Colin on Feb 24, 2010
Latest reply on May 17, 2010 by CraigG

Hi,

  I'm using VDSP++ 5.0 Update 7.

I'm building a target that has two parts; init_code and the main code.

I've chosen to begin the main code at FFA01000 (rather than overlay the init code)

The init code is in a .dxe already built.

 

Under Project Options I have:

  Project:target:type = Loader File

  Project:Load:Options: Initialisation file = init_code.dxe

  LDF:Settings: My program will start running from: Somewhere else: 0xFFA01000

 

I have set the LDF to be "Leave the files in the code, but stop regenerating them"

because it's the only way I've been able to keep my memory map intact.

 

The IDE seem to automatically set:

  Project:Load:Splitter: Enabled, Format=Hex, Maskaddress=29, outputfile=meter.ldr

 

A build then fails with

Linking...
Creating loader file...
[Warning ld0103]: The loader generates no output file because there is no
ROM section in the input file. The loader splits ROM section only
with -RomSplitter switch.
Build completed successfully.

 

It builds the .dxe but not the .ldr

 

If I clear the Project:Load:Splitter:Enable bit,  the IDE  regenerates the .ldf and

the build fails because the generated .ldf is not correct.  When I restore the .ldf

to my version and re-open the project, the bit is set again.

 

At present I have to exit the IDE, edit the .dpj file by hand and change all

"romsplitter>1" to "romsplitter>0" in the Loader options lines.  The build

then completes OK and generated both .dxe and .ldr files:

Linking...
Creating loader file...
Process file: D:\WorkingCopies\Mobile\8020_Meter\Software\trunk\init_codeMeter\asm\Debug\initcode.dxe
Process section: L1_CODE
Section start address: 0xFFA00000
Section byte count: 0x176

 

Process file: MTData\Meter.dxe
Process section: sdram0_bank0
Section start address: 0x4
Section byte count: 0xC69A
Process section: sdram0_bank1
Section start address: 0x400000
Section byte count: 0x4B3C4
Process section: sdram0_bank1_bsz
Section start address: 0x44B3C4
Section byte count: 0x284E4
Process section: sdram0_bank2_disp
Section start address: 0x800000
Section byte count: 0x490F2
Process section: sdram0_bank3_disp
Section start address: 0xC00000
Section byte count: 0x490F2
Process section: L1_data_a_tables
Section start address: 0xFF800000
Section byte count: 0x10
Process section: L1_data_a
Section start address: 0xFF800010
Section byte count: 0x4F48
Process section: bsz_L1_data_a
Section start address: 0xFF804F58
Section byte count: 0x285C
Process section: L1_data_b
Section start address: 0xFF900000
Section byte count: 0x5B64
Process section: bsz_L1_data_b
Section start address: 0xFF905B64
Section byte count: 0x1BF0
Process section: L1_code
Section start address: 0xFFA01000
Section byte count: 0xAFB4
Process section: L1_code_cache
Section start address: 0xFFA10000
Section byte count: 0x3FFA


Build completed successfully.

 

This works OK, until I change a project option and then the .dpj is

re-generated with the bit set again.  I have to then re-edit it by hand.

 

What's the correct way to handle this?

Is there something in the .ldf that makes the IDE set Project:Load:Splitter:Enable?

 

BTW: Another gripe is that there seems to be no way to identify what source files the project is referencing.  I have subversion source control and if I 'check out' and older version into a temporary build directory the project looks OK but the source files were absolute references.  I couldn't tell where the sources were because the 'Properties' pop-up only showed:

     Filename:  D:\WorkingCopies\Mobile\...\display.c

so that paths

    D:\WorkingCopies\Mobile\8020_Meter\Software\trunk\Meter\src\display.c

and

     D:\WorkingCopies\Mobile\8020_Meter\Software\trunk\temp\src\display.c

look the same.

  Again, I've edited the .dpj by hand to make all the references relative but I still can't tell, for sure, which source is referenced.

 

 

Colin Moloney

Outcomes