program will not fit into available memory (flash)

hhh ggg said:

On TI website we found information about reallocation of FLASH ,when we made the relevant setting about reallocation of flash in the linker file lnk_msp430f5325.cmd the compiler does not show any error and code downloaded  

From looking at your attached lnk_msp430f5325.cmd one of the work-arounds suggested in MSP430 linker reports "error #10099-D: program will not fit into available memory" even when there is space has been applied.

hhh ggg said:

but our hardware reseted continuously .we do not understand why it is happening?? There is no hardware problem because we cross verified by commenting some code segment from same code to reduce flash size and our hardware works fine.

The problem could be that the WDT fires during C startup code.

To prevent the Watchdog from firing during the C startup you can add the following to a C source file:

int _system_pre_init(void)
{
     WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer
     return 1;
}

If you are compiling with C++ then you need to use the following, to disable name mangling, to ensure the linker uses the modified _system_pre_init rather than the default version in the run time library (which doesn't disable the watchdog):

extern "C" int _system_pre_init(void)
{
     WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer
     return 1;
}

hhh ggg said:

MSP430F5325 have 64kB Flash, our code size is aprrox 48 KB when we try to build the program we got the below error

Of these 64k of flash, only 47k are in the lower 64k area (16 bit address).

If your code wants to use the remaining flash above 64k (20 bit addressing) large code model needs to be used (which uses 20 bit funciton pointers). It is not sufficient to make th e liker move part of the 16 bit code into the upper memory. Since all function calls will still use a 16 bit address, the code will jump into ram or module memory instead of jumping into the code above 64k.
The compiler won't complain because it doesn't know what you told the linker to do with the code. And the linekr won't complain because it doesn't know that the code it links won't run in upper memory. But the CPU will complain when it jumps into the void.

Note that the interrupt vector tabel entries are 16 bit only, so ISRs must remain in the lower flash area under all circumstances.

Same is true for constants. If you place constants into the flash above 64k, you can only access them when using large data model (using 20 bit data pointers instead of 16 bit).
Normally, the linker script manages all this correctly when you pick the correct code and data model.

Dear Jens-Michael Gross,

Thanks for your suggestion.

In our case, we are at 48K code memory  which is is 16K lower than 64K.. We do not want to go above 64K but utilise the balance 16 K. tHat means we want operate in the lower 64K region.We are not clear about going above 64K. However, as per your suggestion we tried to use different settings like changing the model to  " Large" as well as  "restricted" but did not succeed.

After this , we changed the abi interface in CCS from eabi to Coffabi and changed the "Floating point precision  accepted by complier..." to 32bit  instead of 64 bit. This reduced the code size by 8-10K  (why we do not know???) . As our memory was reduced to around 30K-32K  and temporarily we did not have the issue of exceeding the FLASH section (0xBB80=48k). So the issue was solved temporarily and program was working fine.We thought that we would be able to mange the code within 48K but could not do so. 

Yesterday, we crossed the limit of 48K once again and our program started resetting like earlier.

This time we did not get any complier/linker error like  "Program does not fit ..."   which we had received earlier probably because we are using  abi interface =Coffabi  and floating point =32 bit. We checked the map file and found that linker allocates code to both  FLASH and FLASH2 on its own (this was not the case with abi interface=eabi when we faced this issue first in July 13)  when the FLASH section is exceeded  but the program will continue to reset after few seconds (3-6 secs) repeatedly.

if we interchange the priority of allocation of code in liker map file :      

  .text       : {} > FLASH2 | FLASH  

,the program does not arrive at main()  even after using the function :

int  _system_pre_init(void) {   WDTCTL=WDTPW | WDTHOLD;  return (1)}  

 Only when the code size is reduced below 48K, the program runs Ok.

Is this an issue of CCS version 5.3 not able to allocate the code memory appropriately ?  Should we change to IAR ?

hhh ggg said:

In our case, we are at 48K code memory  which is is 16K lower than 64K..

Well, the 64k limit refers to the address space in which the code resides, not to the filling of the flash memory itself.

Of the lower 64k, only part of it is flash, the rest are ram and hardware registers. Likely, on your MSP (i didn't chekc the datasheet), ht efirst 16 k of the lower 64k are ram, info memory, BSL area and peripherals, and only 48k flash are present in the 16 bit addressing space.

If you take a look at the 'memory organization' chapter in the datasheet, you'll see how memory is organized:

your 64k of flash range from 0x04400 to 0x143FF, so 17 k of it are above the 64k border and can only be utilized with the 20 bit address extensions of the large code model.

hhh ggg said:

changed the "Floating point precision  accepted by complier..." to 32bit  instead of 64 bit. This reduced the code size by 8-10K  (why we do not know???)

64 bit float precision requires more complex (and therefore larger) code to be linked into the binary from the math library. Also, any float variables are twice as large and require more than twice the code to handle them.
Using floating point math is a bad idea anyway. It is big and slow. Use long integers instead (e.g. multiply by 1000 to get 3 digits precision). It's smaller and faster.

hhh ggg said:

Is this an issue of CCS version 5.3 not able to allocate the code memory appropriately ?  Should we change to IAR ?

Indeed, i wonder why you didn't get a linker error. Not because code doesn't fit but because relocating the call references should be a problem (how to put a 20 bit address into a 16 bit address call instruction).

However, you'll need to use the large code model to use all of the 64k flash.