• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 830 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Too large .out/txt release executable

Adde
Intellectual 460 points
Other Parts Discussed in Thread: MSP430F5438, MSP430F2618, MSP430F5418

Hi,

My device is a MSP430F5438 and I'm using CCE Professional v3.1. When I build my debug executable it's larger than 900 kB and when I build it as TXT, it becomes roughly 750 kB. This is way to large since the F5438 only has 256 kB flash.

At first I thought this was due to too much debug information but building it as release gave me the same result (a few kB difference). I have set the "Control speed vs. size" option to 0 to optimize for size but this didn't result in anything big either.

I know that a very similar application (close to the same source code) has been built with a much smaller output file by a collegue using an IAR ARM compiler and ARM target.

Seems like I'm missing something obvious?

 

Even if the debug application is 900 kB I can load it with my debugger and start the application. It behaves strange, suddenly stops running, interrupts ain't working etc. Maybe due to overwritten interrupt code?

Any help is of course much welcome, thank you

/Adde

  • 0
    Guru 58965 points

    The 900 kB and 750 kB you refere to are probably the file size when stored in PC. The actual code size when loaded to the MSP is probably smaller than 245 kB. Can you generate a link map?

  • 0 in reply to old_cow_yellow
    Intellectual 460 points

    You're right, the actual code size is not that big. How do the file size at my PC disk relate to the "absoulte/final" file size?

    I look in my .map file and I see that all of flash and most part of flash2 is occupied. At this point interrupts ain't working, single-steping the code is almost impossible and the CPU sometimes resets itself. I take away some code so that it just fits into flash 1. Now everything work great. When I at this point make the application a little bit larger, so that some code ends up in flash2, makes it behaves strange again. It seems like interrupts that are generated takes up the execution somewhere else in memory than at the interrupt vector, but this is just my "feeling".

    I'm quite certain that this has to do with the fact that the linker places some code in flash2 (which it has to since the app. is big), and then it behaves buggy and strange. I'm also quite certain that this has happen to someone else :-)

    Anyone? And thank you old_cow_fellow for the hint about the map-file.

                  origin         length         used           unused

    FLASH 00005c00 0000a380 0000a238 00000148 RWIX   <-- WORKING

    FLASH 00005c00 0000a380 0000a380 00000000 RWIX   <-- NOT WORKING

    The linker does not produce any warnings or errors. The interrupts seems to be correct in the map-file.

    /Adde

  • 0 in reply to Adde
    Prodigy 20 points

    I am having similar issues with a msp430F2618 using v3.1 Pro.  FLASH is completely full and FLASH2 has 0x5cf7 used.  When I try to debug I get stopped at code in my isrs that do not have breakpoints set.  If I comment out relatively small amounts of code in the isr can get the unwanted breakpoint to shift to different isr and sometimes even disappear so I can run the code in debug again.  I am using the text:_isr pragma to force the isr code in FLASH not FLASH2.  I am wondering if I would be better off trying the beta version on new compiler?

  • 0 in reply to apdm307
    Intellectual 460 points

    Hi, I have now solved the problem after reading through some chapters in the compiler manual. Try this if it's applicable to you apdm307.

    I used the macros PLACE_INTERRUPT(func) defined in my device header-file to place all interrupts into flash1, so that my .map-file look like this:

    .text:_isr

    * 0 00005f04 00000232

    00005f04 000000a2 uartdrv.obj (.text:_isr:USCI_A2_ISR)

    00005fa6 000000a0 uartdrv.obj (.text:_isr:USCI_A0_ISR)

    00006046 00000054 misc.obj (.text:_isr:PORT2_ISR)

    0000609a 00000040 tmrdrv.obj (.text:_isr:TIMERB1_ISR)

    000060da 0000003e tmrdrv.obj (.text:_isr:TIMER1_A1_ISR)

    00006118 0000001e rts430xl.lib : boot.obj (.text:_isr:_c_int00)

    Example: PLACE_INTERRUPT(

    USCI_A1_ISR)

    /Adde

  • 0 in reply to apdm307
    Intellectual 460 points

    I re-read your message and saw that I missed out the part where you write that you already use the pragma to move interrupts into lower FLASH. I have done the same thing, and my experience is that the curious interrupt phenomenon have decreased. BUT still, I (like you) get stopped in ISRs although I don't have any breakpoints set. After I get stopped the program usually halts execution or get into an infinite assembly-code loop hard to debug. Most trouble seems to be related to UART interrupts but this might be a co-incidence.

    Have you find any explanation to this behaviour? Anyone else? 

    /Adde

  • 0 in reply to Adde
    Prodigy 20 points

    What I tried over the weekend to get debugging again was to create a dead space on both sides of the isr memory space by decreasing the FLASH and FLASH2 memory segment size in lnk_msp430f2618.cmd.  Initially I tried 8 bytes and when I got another unset breakpoint (at a different line)  occurring in a uart isr I tried 16 bytes.  So far this has worked for me and I can continue to use the debugger.  Earlier I had a problem with a structure displaying incorrectly that TI confirmed was a problem with v 3.1 but did not occur in new v4 coming out soon.

  • 0 in reply to apdm307
    Intellectual 460 points

    Sounds ok, but I'm not following what you mean or how you do. Do you mean decrease or increase the FLASH and FLASH2 memory segment?

    In my lnk_msp430f5438.cmd I doubt I can set the memory segment size, how do you do this?

     

  • 0 in reply to Adde
    Prodigy 180 points

    Hi guys,

    I am having the same problem.  Did you ever get this resolved? And how?

    Thanks in advance.

  • 0 in reply to gcgplge
    Prodigy 170 points

    Hi,

    I also got a similar issue. FLASH has finished up and I am now in FLASH2, and the debugger starts giving problem. At one time the command "__bis_SR_register(GIE)" would cause the program to end up nowhere. Now even a for loop is also ending up lost.

    Compile is ok, no errors. Large model selected, rts430xl.lib selected.

    Is there something wrong with the debugger setting? Is there any special debugger settings in order to use FLASH2 (since it's no longer in 16-bit address)?

    Mine is CCE Pro 3.1 + MSP-FET430UIF + MSP430F5418.

**Attention** This is a public forum