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 : "Error[e104]: Failed to fit all segments into specified ranges."

Other Parts Discussed in Thread: CC2541, CC2540

Hi,

I have a copy of the application code which was working fine with CC2541. After that I need to add few lines of code for new feature. After adding that I tried to compile it to generate the OAD image, but compiler was giving following error, though we have a enough free flash memory available:

Linking
Error[e104]: Failed to fit all segments into specified ranges. Problem discovered in segment BANKED_CODE. Unable to place 79 block(s) (0x1bde5 byte(s) total) in
0x1bdde byte(s) of memory. The problem occurred while processing the segment placement command
"-P(CODE)BANKED_CODE=_CODE_BEG-_CODE_END,_BANK1_BEG-_BANK1_END,_BANK2_BEG-_BANK2_END,_BANK3_BEG-_BANK3_END,_BANK4_BEG-_BANK4_END", where at the moment of placement
the available memory ranges were "CODE:6f4c-7ff7,CODE:18000-1ffff,CODE:28000-2ffff,CODE:38000-3ffff,CODE:482ce-4afff"
Error while running Linker

I am using default XCL file, "C:\Texas Instruments\BLE-CC254x-1.4.0\Projects\ble\common\cc2540\cc254x_f256_imgB.xcl". 

Following is the output of *.map file for successful case i.e. before adding new code:

126 950 bytes of CODE memory (+ 26 range fill )
35 bytes of DATA memory (+ 87 absolute )
7 193 bytes of XDATA memory
194 bytes of IDATA memory
8 bits of BIT memory
718 bytes of CONST memory

This becomes blocker issue for us. Please help us to resolve this ASAP.

Thanks,

Dhaval

  • Hi Dhaval,

    How much code is getting linked in when you add the few new lines? You may not have enough banks allocated to handle the new code. Can you share more specifics on your change?

    Best wishes
  • Hi JXS,

    I didn't get your question. Can you please elaborate and also how can I check that?

    I need to add new feature, where I am expecting some information from connected Central Device, on a certain BLE Service. And based on that I need to perform few operations.

    Also, it would be great if you can help us on following:

    1. We have a 'const' array of 200 bytes, which is getting placed in CODE section of memory. Can we move it to some other place, which help us to resolve above mentioned issue? We tried the attributes '__xdata' and '__xdata_rom', as mentioned in IAR Compiler Reference Guide, but that didn't help.

    2. Can you provide some other suggestion, that we need to incorporate in our code to optimize the CODE memory?

    Thanks,

    Dhaval

  • Hi JXS,

    Can you please suggest anything or provide any feedback regarding Dhaval's question.

    We also have similar issue.

    We have optimized our code by using the below techniques:

    1. Used the __near_func memory attribute for all the static functions.

    2. For all the bool variables, "hal_types.h" defines them as unsigned char.

        But these variables with bool types, still occupy 1-byte even though they hold just 1-bit of value.

        So by referring the IAR Compiler document, we found to use __no_init and  __bit memory attributes.

        By using the __bit memory attribute, the variable will be placed in the bit-addressable memory region.

        But by using these attributes, we were getting compiler error - to use these attributes with boolean type.

        So by some trial and error, we found an undocumented type _Bool.

        So by using the variable as below, we were able to optimize the variables which were truely of the nature of boolean types:

    __no_init __bit static _Bool myBoolVar;

    3. For the uint8 variables, we used the __idata memory attribute.

    4. For const arrays, we used the __xdata memory attribute.

    We were able to optimize our code by around ~100 bytes and we have tested our code. It is working fine.

    But by using all the above mentioned memory attributes, do we need to take care of anything.

    Because some of the uint8 variables which are placed in the __idata sections, are being used in ISR.

    Please do let us know if you have any suggestions or recommendations before we use these memory attributes in our released code.

    Awaiting your reply.

    Thanks,
    Sunny

  • It looks like you may be running out of RAM / flash. You can fix a potential RAM problem by reducing the heap size via the INT_HEAP_LEN preprocessor define. By continuing to decrease this value, you should find enough RAM. However, this may also cause your code to break at run-time as a certain amount of heap will be needed by your application and the stack. This can be profiled using the OSALMEM_PROFILER define.

    If you are still receiving a compiler error after reducing the heap, you are likely out of flash. You can try:
    - Maximize the Image-B area (while minimizing the Image-A area). See section 12 of the OAD guide.
    -Using a architecture where image A is a small oad-only image: processors.wiki.ti.com/.../BLE_Large_Image_OAD
  • Hi Tim,

    Thank you for your reply.

    But can you please provide information on the memory attributes that we have mentioned previously, i.e. __xdata, __no_init __bit, __bdata, __idata if they will have any run-time implications.

    Also about the undocumented type specifier _Bool.

    Awaiting your reply.

    Thanks,
    Sunny

  • These are all documented by IAR in Help->C/C++ Compiler Reference Guide.
  • Hi Tim,

    Thank you for the reply.

    We have already gone through the IAR Help -> C/C++ Compiler Reference Guide.

    We understand that by using some memory attributes, there might be slowness in the system e.g. __idata memory attribute may cause slower data access as compared to objects in data memory.

    But apart from all the documented details, is there any other thing that we should be careful of, e.g. stack / heap issues, or some random failures, any issues if we use the whole bit-addressable memory + the whole __idata and __data section of the Internal data memory space by using the memory attributes, etc.

    Also can you please let us know regarding the usage of the data type _Bool. Is it safe to use because we have found no literature mentioning this data type.

    Awaiting your reply.

    Thanks,
    Sunny

  • Hi Tim,

    Can you please let us know for the queries posted in the previous thread.

    Awaiting your reply.

    Thanks,
    Sunny

  • We only support what is done by default in the linker files included with the installer so I can not provide any information that is not in the IAR C/C++ compiler guide.

    Please see my original post for suggested methods to increase OAD image code space.

  • Hi Tim,

    Thanks for the reply.

    Thanks,
    Sunny