Compiler/MSP430F2618: error #10099-D: Program will not fit into available memory, placement with alignment fails for section ".cinit". after changing compiler from TI v4.0.0 B1 to TI16.9.3.LTS

Rishit Borad said:

which worked alright when i was on an older compiler (v4.0.0.B1) and after changing the compiler (to V6.9.3.LTS)

Those compiler versions are 6 years apart.  There is a dependence between the compiler version and the linker command file (the file named lnk_msp430f2618.cmd).  We work hard to make them as independent as possible.  But 6 years is a bit much.  It is not surprising you have run into problems.

Your best bet is to upgrade your entire Code Composer Studio environment.  This upgrades both the compiler, and the linker command files, and is much more likely to work.  Is this practical for you?

Thanks and regards,

-George

Thanks for the reply George.

I did change my CCS V5 to CCSv7.2.0. As I imported the project that i used in CCS v5 to CCS v7xx it came with the old .cmd file. is there a way I can generate/use a .cmd file and change it according to my needs? or can I just copy it from an exesting TI example projects?

Let me know if that wasn't the suggestion you made.

Also, output format with compiler V4.0.0 is COFF while with V16.9.3 its ELF. Does it change the way the the whole system works? i am trying to figure that out right now, hopefully i find something.

Thanks and Regards,
Rishit

CCSv7 comes with some default linker command files. They can be found in the \ccsv7\ccs_base\msp430\include directory within the CCS installation. You can find the one for the specific device you are using, copy it into your project and tailor it to your needs.

Rishit Borad said:

Also, output format with compiler V4.0.0 is COFF while with V16.9.3 its ELF. Does it change the way the the whole system works?

There are some factors to be taken into consideration when moving from COFF to ELF. This wiki page covers the migration details. The page was written for C6000 devices so not all aspects may be relevant for MSP430, but all of the main concepts will apply to MSP430 as well.

As you probably realized already, the compiler version in CCSv7.2 (16.9.3.LTS) does not support COFF. The last version that supported COFF is 4.4.x. The ideal long-term solution would be to get your project working with the latest compiler/ELF. However, if you are in a near-term crunch, you can install and use compiler version 4.4.x with CCS 7.2. To install, follow the steps in this section and choose the latest 4.4.8. Then you can set the project to use version 4.4.8 for the build. 

Hello Aarti,

Thanks for the reply.

AartiG said:

CCSv7 comes with some default linker command files. They can be found in the \ccsv7\ccs_base\msp430\include directory within the CCS installation. You can find the one for the specific device you are using, copy it into your project and tailor it to your needs.

This is really helpful, i was able to get rid of warnings except the one below: 

The system cannot find the path specified.
srec_cat: .\csac_cc4.txt: 3954: warning: The data presented for CRC calculation
    has at least one hole in it. This is bad. It means that the in-memory
    calculation performed by your embedded system will be different than the
    calculation performed here. You are strongly advised to use the --fill 0xFF
    filter *before* this CRC filter to ensure both calculations are using the
    same byte values. See srec_info(1) for how to see the holes.

The wiki page says "COFF adds a leading underscore to symbol names, but the EABI does not. Assembly file references to symbols will need special handling.".

(As i've mentioned in my original question) When I am using the latest compiler v16.9.3 LTS, and edit ".cinit     : {} > FLASH | FLASH2" in linker command file, it compiles fine but breaks before application code starts in run-time. 

Turns out my BSL jumps to the ISR31() where symbol "_c_init00" is written to start the firmware. Because ELF format dont have underscores, BSL might not be able to find that symbol (I am assuming) and breaks. I also observed that when output format is ELF it has the original problem in both compilers V4.4.8 and V16.9.3 LTS. When output format is COFF it compiles alright in both compilers V4.0.0 B1 and v4.4.8. 

Is there a way i can change the symbol in ISR31()?

Ultimate goal for me is to have Double-Precision Floating point support and compiler V16.9.3 LTS has it. Changing the Compiler to V4.4.8 wouldn't help. 

I will appreciate it if you could help me with any information you have on this.

Regards,

Rishit

 

It's _c_int00, with only one 'i'. This name is an exception to the general rule that COFF names have an extra underscore where EABI names do not; the symbol _c_int00 has the same linkname in both COFF and EABI. If your program links without error, you do not have a problem with EABI finding the symbol _c_int00; it must be some other problem.

Rishit Borad said:

(As i've mentioned in my original question) When I am using the latest compiler v16.9.3 LTS, and edit ".cinit     : {} > FLASH | FLASH2" in linker command file, it compiles fine but breaks before application code starts in run-time. 

I'm not sure if you've already resolved this issue, but I wanted to mention another thing that just came to mind. Is it possible that the watchdog is firing and resetting the device during the initialization routine? This can happen if there are a large number of variables to initialize thereby causing the init code to run longer. The symptom of this is not being able to reach your main() function successfully.

I mention this because this was initially a COFF project that was created with a very old version of the compiler. With COFF, uninitialized variables were not auto-initialized to zero (this was left to the user to do), however in ELF the variables are auto-initialized by the tools and that could increase startup time.

With the newer compiler tools, there is an option to hold the watchdog timer during auto-initialization. Please see this FAQ topic and ensure that this option is enabled in your project.

Aarti,

Thanks for replying.

I delayed changing the compiler due to time constraint and worked to find the solution to my problem on the older compiler with the Floating point double precision.

However, after your replied here I opened up my project to check the status of the option you are talking about and it did compile right without any more changes being made and run without breaking. Turns out when I closed this project last week I made few changes to the .cmd file after learning things from your suggestion from previous answer: "CCSv7 comes with some default linker command files. They can be found in the \ccsv7\ccs_base\msp430\include directory within the CCS installation. You can find the one for the specific device you are using, copy it into your project and tailor it to your needs." and it compiled right for me. But now it seems i have some trouble with PostBuild file as at run-time my board is not reacting to any updates in my project I made before compiling. I am pushing this for a week more as I am running out of time but for sure I need to move my system to the new toolchain in near future. I will get back to you in a week or so with more information.

AartiG said:

Please see this FAQ topic and ensure that this option is enabled in your project.

This option was already enabled for me but information you provided is good to know.  

Also, I really appreciate you spending your time.

Regards,

Rishit

Aarti,

I did some experiments with both my BSL (Secondary Boot Loader) and Firmware projects in terms of changing compiler and here's what I found.

1) BSL works with both compiler versions 16.9.3(eabi) and 4.8.8(COFF)

2) Firmware works only with compiler v4.8.8(COFF) irrespective of what BSL compiler version is.

3) BSL(with compiler v16.9.3 or v4.8.8) jumps to ISR31 and where there is a starting address of the Firmware.

When v4.8.8 compiled firmware is loaded in the flash and I put a breakpoint at ISR31() while running from BSL, i see the ENTRY POINT SYMBOL address  of the firmware (0x5a8a) stored as data at address ISR31 (0x3148). *(0x3148) = 0x5a8a;

When v16.9.3 compiled is loaded in the flash and check to see data at address ISR31(0x3148), its all 'F's. *(0x3148) = 0xffff;

Note: To compile my firmware right with v16.9.3 i had to go through some alteration in .cmd file, please see original question above where i am talking about .cinit problem.

My questions are,

What am i doing wrong that data stored at ISR31() is not the first address of the firmware but all Fs.??

Is the workaround for .cinit to compile my program causing overwriting in other sections?

What should I look for in order to get answer to these questions?

Thanks in advance,

Regards,

Rishit

Enclosed:

1) Firmware Map and CMD files

2) BSL MAP and CMD files

3) Firmware build Log.

FirmwareBuildingLog.zip

Rishit Borad said:

When v4.8.8 compiled firmware is loaded in the flash and I put a breakpoint at ISR31() while running from BSL, i see the ENTRY POINT SYMBOL address  of the firmware (0x5a8a) stored as data at address ISR31 (0x3148). *(0x3148) = 0x5a8a;

When v16.9.3 compiled is loaded in the flash and check to see data at address ISR31(0x3148), its all 'F's. *(0x3148) = 0xffff;

How is the entry point address of firmware stored in the BSL code? 

If this works with v4.8.8, perhaps comparing the linker command file and map file generated with 4.8.8 with those generated by 16.9.3 may also shed some light.

Thanks for the reply Aarti,

AartiG said:

How is the entry point address of firmware stored in the BSL code? 

BSL calls ISR31() after some primary checksum check. So BSL Jumps to the memory address 0x3148. 0x3148 is a part of Firmware memory, it is Firmware's responsibility to write its starting address at address 0x3148. In our case data stored at address 0x3148 is 0x5a8a where 0x5a8a is the starting address of the firmware.   

Lately, I have decided to go step-by-step rather than jumping directly on v16.9.3 EABI format. I am converting my v4.8.8 COFF format project to V4.8.8 EABI format now. And then it will be easier to make v16.9.3 conversion as they both support same output format EABI.

AartiG said:

If this works with v4.8.8, perhaps comparing the linker command file and map file generated with 4.8.8 with those generated by 16.9.3 may also shed some light.

If you look at the .cmd/map file, there is a Section created named XFER (origin 0x3100, length 0x50) followed by FLASH (origin 0x3150, length 0xcab0). XFER memory region is handled by Firmware. This section stores CSAC_applvect.obj in our case. CSAC_applvect.obj apparently is the vector table for the firmware. In COFF format XFER size used is 0x4c and in EABI format its empty. Point to note here is, I am changing nothing but output format from COFF to EABI. ( size used is 0x4c because first 4 bytes of the section are for CRC added by post-build script)

Also, makefile has CSAC_applvect.obj mention in it for both formats, in case that is relevant.

Question is, what is happening differently in EABI that my CSAC_appvect.obj is not being written in the XFER section? or if you can direct me where should i be looking next. 

Thanks for your help. 

Regards,

Rishit

Attached: map file for Firmware_COFF and Firmware_EABI.

Firmware_map_EABI.txt

Firmware_map_COFF.txt