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.

Linker Error e104 during Multi-file compilation

Other Parts Discussed in Thread: CC2530, Z-STACK

Hi,

We are implementing an On-Off light switch using Zstack 2.4.0-1.4.0 on our custom hardware which is based on CC2530.

The workspace was build using GenericApp as the base and have adapted to build a proprietary SampleLight workspace.We are already in the completion phase of the project when we noticed an error occurring while Multi-file Compilation option was selected.

Error[e104]: Failed to fit all segments into specified ranges. Problem discovered in segment BANKED_CODE. Unable to place 1 block(s) (0x1233c 
byte(s) total) in 0x27702 byte(s) of memory. The problem occurred while processing the segment placement command 
"-P(CODE)BANKED_CODE=_CODE_START-_CODE_END,0x18000-0x1FFFF,0x28000-0x2FFFF,0x38000-0x3FFFF,0x48000-0x4FFFF,0x58000-0x5FFFF,0
x68000-0x6FFFF,0x78000-0x7F7FF", where at the moment of placement the available memory ranges were 
"CODE:2dff-7fff,CODE:1810a-1ffff,CODE:28000-2ffff,CODE:38000-3ffff,CODE:48000-4ffff,CODE:58000-5ffff,CODE:68000-6ffff,CODE:78000-7f7ff"
Error while running Linker

This error was seen ONLY when a MULTI-FILE Compilation is done.In normal compilation no error is observed.The IAR version used is 7.60.

The linker file configuration is as follows.

////////////////////////////////////////////////////////////////////////////////
//
//
// Segment limits
// --------------
//
//
// XDATA available to the program.
//
// Reserving address 0x0 for NULL.
-D_XDATA_START=0x0001
-D_XDATA_END=0x1EFF
//
//
// The 8052 IDATA is overlayed on the SoC XDATA space from 0x1F00-0x1FFF.
//
-D_IDATA_END=0xFF              // Last address of Idata memory.
//
//
//    CODE
//
-D_CODE_START=0x0000
-D_CODE_END=0x7FFF             // Last address for ROOT bank.
//
-D_FIRST_BANK_ADDR=0x10000
//
//
//
// Special SFRs
// ------------
//
//    Register bank setup
//
-D?REGISTER_BANK=0             // Default register bank (0,1,2,3).
-D_REGISTER_BANK_START=0       // Start address for default register bank (00,08,10,18).
//
//
//    PDATA page setup
//
-D?PBANK_NUMBER=00             // High byte of 16-bit address to the PDATA area.
//
//
//    Virtual register setup
//    ----------------------
//
-D_BREG_START=0x00             // The bit address where the BREG segments starts.
                               // Must be placed on: _BREG_START%8=0 where _BREG_START <= 0x78.
-D?VB=0x20                     // ?VB is used when referencing BREG as whole byte.
                               // Must be placed on: ?VB=0x20+_BREG_START/8.
//
////////////////////////////////////////////////////////////////////////////////



////////////////////////////////////////////////////////////////////////////////
//
// IDATA memory
//

// Setup "bit" segments (only for '__no_init bool' variables).
-Z(BIT)BREG=_BREG_START
-Z(BIT)BIT_N=0-7F

-Z(DATA)REGISTERS+8=_REGISTER_BANK_START
-Z(DATA)BDATA_Z,BDATA_N,BDATA_I=20-2F
-Z(DATA)VREG+_NR_OF_VIRTUAL_REGISTERS=08-7F
-Z(DATA)PSP,XSP=08-7F
-Z(DATA)DOVERLAY=08-7F
-Z(DATA)DATA_I,DATA_Z,DATA_N=08-7F

-U(IDATA)0-7F=(DATA)0-7F
-Z(IDATA)IDATA_I,IDATA_Z,IDATA_N=08-_IDATA_END
-Z(IDATA)ISTACK+_IDATA_STACK_SIZE#08-_IDATA_END
-Z(IDATA)IOVERLAY=08-FF

////////////////////////////////////////////////////////////////////////////////
//
// ROM memory
//
//
// The following segments *must* be placed in the root bank. The order of
// placement also matters for these segments, which is why we use the -Z
// placement directive.
//
-Z(CODE)INTVEC=_CODE_START
-Z(CODE)BIT_ID,BDATA_ID,DATA_ID,IDATA_ID,IXDATA_ID,PDATA_ID,XDATA_ID=_CODE_START-_CODE_END
//
// Sleep PCON instruction must be 4-byte aligned.
//
-D_SLEEP_CODE_SPACE_START=(_CODE_END-7)
-D_SLEEP_CODE_SPACE_END=(_CODE_END)
-Z(CODE)SLEEP_CODE=_SLEEP_CODE_SPACE_START-_SLEEP_CODE_SPACE_END
//
// The following segments *must* be placed in the root bank, but the order
// of placement within the root bank is not important, which is why we use the
// -P directive here.
//
-P(CODE)CSTART,BANK_RELAYS,RCODE,DIFUNCT,NEAR_CODE=_CODE_START-_CODE_END
//
// Setup for constants located in code memory:
//
-P(CODE)CODE_C=_CODE_START-_CODE_END
//
// Define segments for const data in flash.
// First the segment with addresses as used by the program (flash mapped as XDATA)
-P(CONST)XDATA_ROM_C=0x8000-0xFFFF
//
// Then the segment with addresses as put in the hex file (flash bank 1)
-P(CODE)XDATA_ROM_C_FLASH=0x18000-0x1FFFF
//
// Finally link these segments (XDATA_ROM_C_FLASH is the initializer segment for XDATA_ROM_C,
// we map the flash in the XDATA address range instead of copying the data to RAM)
-QXDATA_ROM_C=XDATA_ROM_C_FLASH
//
// The directive below ensures that the remaining space in the root bank gets
// filled, then starts filling the banks.
//
-P(CODE)BANKED_CODE=_CODE_START-_CODE_END,0x18000-0x1FFFF,0x28000-0x2FFFF,0x38000-0x3FFFF,\
0x48000-0x4FFFF,0x58000-0x5FFFF,0x68000-0x6FFFF,0x78000-0x7F7FF

////////////////////////////////////////////////////////////////////////////////
//
// XDATA memory
//

-Z(XDATA)XSTACK+_XDATA_STACK_SIZE=_XDATA_START-_XDATA_END
-Z(XDATA)XDATA_Z,XDATA_I=_XDATA_START-_XDATA_END
-P(XDATA)XDATA_N=_XDATA_START-_XDATA_END

-cx51

////////////////////////////////////////////////////////////////////////////////
//
// Texas Instruments device specific
// =================================
//
//
// Layout of CODE banks
// -------------------
//
//-D_BANK0_START=0x08000
//-D_BANK0_END=0x0FFFF
//
//-D_BANK1_START=0x18000
//-D_BANK1_END=0x1FFFF
//
//-D_BANK2_START=0x28000
//-D_BANK2_END=0x2FFFF
//
//-D_BANK3_START=0x38000
//-D_BANK3_END=0x3FFFF
//
//-D_BANK4_START=0x48000
//-D_BANK4_END=0x4FFFF
//
//-D_BANK5_START=0x58000
//-D_BANK5_END=0x5FFFF
//
//-D_BANK6_START=0x68000
//-D_BANK6_END=0x6FFFF
//
//-D_BANK7_START=0x78000
-D_BANK7_END=0x7FFFF
//
//
// Include these two lines when generating a .hex file for banked code model:
-M(CODE)[(_CODEBANK_START+_FIRST_BANK_ADDR)-(_CODEBANK_END+_FIRST_BANK_ADDR)]*\
_NR_OF_BANKS+_FIRST_BANK_ADDR=0x8000
//
//
// Internal flash used for NV address space: reserving 6 pages.
// NV memory segment size must coincide with page declarations in "hal_board_cfg.h" file.
//
-D_ZIGNV_ADDRESS_SPACE_START=(((_NR_OF_BANKS+1)*_FIRST_BANK_ADDR)-0x3800)
-D_ZIGNV_ADDRESS_SPACE_END=(_ZIGNV_ADDRESS_SPACE_START+0x2FFF)
-Z(CODE)ZIGNV_ADDRESS_SPACE=_ZIGNV_ADDRESS_SPACE_START-_ZIGNV_ADDRESS_SPACE_END
//
//
//
// The last available page of flash is reserved for special use as follows
// (addressing from the end of the page down):
//   16 bytes  Lock bits
//    8 bytes  IEEE address space (EUI-64)
//   22 bytes  Device Private Key (21 bytes + 1 byte pad to NV word size)
//   22 bytes  CA Public Key (22 bytes)
//   48 bytes  Implicit Certificate (48 bytes)
// 1932 bytes  Reserved for future Z-Stack use (1932 bytes)
//
//-D_LOCK_BITS_ADDRESS_SPACE_START=(((_NR_OF_BANKS+1)*_FIRST_BANK_ADDR)-0x10)
//-D_LOCK_BITS_ADDRESS_SPACE_END=(_LOCK_BITS_ADDRESS_SPACE_START+0x0F)
//-Z(CODE)LOCK_BITS_ADDRESS_SPACE=_LOCK_BITS_ADDRESS_SPACE_START-_LOCK_BITS_ADDRESS_SPACE_END
//
//-D_IEEE_ADDRESS_SPACE_START=(_LOCK_BITS_ADDRESS_SPACE_START-0x08) // Hot fix for extended address-do not read from lock bits since custom ext. address is used
-D_IEEE_ADDRESS_SPACE_START=(_BANK7_END-0x08)
-D_IEEE_ADDRESS_SPACE_END=(_IEEE_ADDRESS_SPACE_START+0x07)
-Z(CODE)IEEE_ADDRESS_SPACE=_IEEE_ADDRESS_SPACE_START-_IEEE_ADDRESS_SPACE_END
//
-D_DEV_PRIVATE_KEY_ADDRESS_SPACE_START=(_IEEE_ADDRESS_SPACE_START-0x16)
-D_DEV_PRIVATE_KEY_ADDRESS_SPACE_END=(_DEV_PRIVATE_KEY_ADDRESS_SPACE_START+0x15)
-Z(CODE)DEV_PRIVATE_KEY_ADDRESS_SPACE=_DEV_PRIVATE_KEY_ADDRESS_SPACE_START-_DEV_PRIVATE_KEY_ADDRESS_SPACE_END
//
-D_CA_PUBLIC_KEY_ADDRESS_SPACE_START=(_DEV_PRIVATE_KEY_ADDRESS_SPACE_START-0x16)
-D_CA_PUBLIC_KEY_ADDRESS_SPACE_END=(_CA_PUBLIC_KEY_ADDRESS_SPACE_START+0x15)
-Z(CODE)CA_PUBLIC_KEY_ADDRESS_SPACE=_CA_PUBLIC_KEY_ADDRESS_SPACE_START-_CA_PUBLIC_KEY_ADDRESS_SPACE_END
//
-D_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_START=(_CA_PUBLIC_KEY_ADDRESS_SPACE_START-0x30)
-D_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_END=(_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_START+0x2F)
-Z(CODE)IMPLICIT_CERTIFICATE_ADDRESS_SPACE=_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_START-_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_END
//
-D_RESERVED_ADDRESS_SPACE_START=(_IMPLICIT_CERTIFICATE_ADDRESS_SPACE_START-0x78C)
-D_RESERVED_ADDRESS_SPACE_END=(_RESERVED_ADDRESS_SPACE_START+0x78B)
-Z(CODE)RESERVED_ADDRESS_SPACE=_RESERVED_ADDRESS_SPACE_START-_RESERVED_ADDRESS_SPACE_END
//
////////////////////////////////////////////////////////////////////////////////

The following are my questions

1.Can i just ignore this error and move forward by normal compilation and not selecting a Multi- File compilation?

2.If this is an serious error, how do i resolve it? What effects it will have on my code during run-time?

3.The optimization level used is High-Size.But if my code size is less than 188KB, it goes into a hung state in NV initialization module.Why is this happening?

We suspect some banking related error occurring here.Kindly guide us ASAP as this is very critical for our project delivery.

 

  • Let me take a crack at answering your questions:

    1.Can i just ignore this error and move forward by normal compilation and not selecting a Multi- File compilation? No, this linker error indicates that it could not place all code blocks into the defined memory segments, so it could not produce a proper program image. Specifically, it could not place a block of size 0x1233C since each of the available flash memory segments contain only 0x10000 bytes.

    2.If this is an serious error, how do i resolve it? What effects it will have on my code during run-time? This is a serious error and you must resolve it before you can load and run your program on the CC2530. Is there a particular reason that you are using multi-file compilation - it does not appear that your total program size (0x27702) should have any problem fitting in the available flash memory? If you choose to use multi-file compilation, do it with smaller groups of source files.

    3.The optimization level used is High-Size.But if my code size is less than 188KB, it goes into a hung state in NV initialization module.Why is this happening? Is this problem happening on the build where you do not use multi-file? I quickly looked over the .xcl file you provided and did not see any glaring issues - have you changed it from the original?

    We suspect some banking related error occurring here.Kindly guide us ASAP as this is very critical for our project delivery.

  • Hi,

    Please see my queries inline

    1.Can i just ignore this error and move forward by normal compilation and not selecting a Multi- File compilation? No, this linker error indicates that it could not place all code blocks into the defined memory segments, so it could not produce a proper program image. Specifically, it could not place a block of size 0x1233C since each of the available flash memory segments contain only 0x10000 bytes.

    2.If this is an serious error, how do i resolve it? What effects it will have on my code during run-time? This is a serious error and you must resolve it before you can load and run your program on the CC2530. Is there a particular reason that you are using multi-file compilation - it does not appear that your total program size (0x27702) should have any problem fitting in the available flash memory? If you choose to use multi-file compilation, do it with smaller groups of source files.

    [Sumitra Vengalil ] According to your reply i understand that this error (e[104]) is observed only during multi-file compilation(I verified the same with the SampleLight workspace provided by TI in the Home Automation Sample and found that same error is found there if you give a multi-file compilation).

    There is no particular reason for using Multi-File Compilation.Since no compilation errors are observed using NORMAL compilation( after De-selecting multi-file option) i plan to proceed with it.

     

    3.The optimization level used is High-Size.But if my code size is less than 188KB, it goes into a hung state in NV initialization module.Why is this happening? Is this problem happening on the build where you do not use multi-file? I quickly looked over the .xcl file you provided and did not see any glaring issues - have you changed it from the original?

    [Sumitra Vengalil ] Yes. This problem happens on the buid where i DO NOT use multi-file compilation.I am using the same linker file which was included in the post and the only change there, is the location provided for IEEE address start.I had changed it from

    -D_IEEE_ADDRESS_SPACE_START=(_LOCK_BITS_ADDRESS_SPACE_START-0x08) to -D_IEEE_ADDRESS_SPACE_START=(_BANK7_END-0x08)

    This problem still remains unresolved.Ideally any CODE size <= 256KB should run without any issues.

    I have also observed that any code size between 210KB to 225KB produces the same issue(it never comes out of NV inititalization). Due to this i am forced to limit code size to  > = 188KB and <= 210KB

    Why would the final CODE size have an effect  during run-time as long as it is less than 256KB? How do i resolve this ?

     

     

     

     

     

  • Hi,

    I would recommend the following to save yourself some headaches unless you have a compelling reason to do otherwise:

    1) Since you are building an on/off light switch, you should use the SampleSwitch project to start with, not GenericApp. I assume your intent is to make this a ZCL based application.

    2) Don't change the .xcl file configuration from the default.

  • You wrote:

    I am using the same linker file which was included in the post and the only change there, is the location provided for IEEE address start.I had changed it from

    -D_IEEE_ADDRESS_SPACE_START=(_LOCK_BITS_ADDRESS_SPACE_START-0x08)   to   -D_IEEE_ADDRESS_SPACE_START=(_BANK7_END-0x08)

    What you have done with this change is to move the IEEE space into the lockbits space - this will cause disaster when an IEEE address gets written because any '0' bits in the IEEE address will lock a flash page corresponding to the associated bit in the 16-byte structure (last 16 bytes of the last flash page on CC2530F256). See section 3.4 of the "CC253x System-on-Chip...User's Guide" (SWRU191) for details on how the lock bits work.

    It is quite possible that one or more of your NV pages are getting locked by this problem, probably causing your observation of "it never comes out of NV inititalization".

    I really can't think of any good reason for you to move the default storage location of the IEEE address - but if you must, put it somewhere other than the last flash page. Or the NV pages, for that matter. Have you tried your application with the unmodified .xcl file? I would suspect that the NV initialization problem will not be observed if you do.