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.

CCS/msp430f4783: debug and release code size

Part Number: MSP430F4783
Other Parts Discussed in Thread: MSPWARE

Tool/software: Code Composer Studio


I have a question about the code size differences between debug and release builds.

I am using ccs 6.1.3 with 15.12.2.lts on 32 bit Linux. I am not using mspware or driverlib.

A few years ago I developed a small battery operated dredging depth calibration

unit based on a f4783 mcu. Now I have a few units back for upgrade purposes and

I wanted to remotely control IO lines, and more, that control the inner workings of the unit.

So I implemented a command interpreter which I first tested on a fr6989 launchpad.

The Flash and RAM code size of the debug and release builds are respectively :

13596 - 900

9584 - 900

So well within the available memory size of the f4783. But when I try to run a debug

session the RAM size grows to 2464 bytes :

MSP430: Loading complete. There were 13596 (code) and 32 (data) bytes written

to FLASH/FRAM. The expected RAM usage is 2464 (uninitialized data + stack) bytes.

The stack and heap are set to 80 bytes both.

The .map file also shows 900 bytes RAM (maybe the "memory allocation" window

gets it's info from there ?).

I know and understand that debugging functionality adds some code. What I do

not understand is why there is no error on the code size exceeding the limit of

the f4783 or is there no such check ?

Is there a way to know for sure how much code gets added to the debug size ?

(other then subtracting the reported code sizes)

The problem now with my program is that the previous command entered is the one

that gets executed when entering the next command.

I have not found out yet if things are related.


  • I have solved the command's lagging 1 behind issue. It turned out that I checked
    for a magical character to start the command interpreter at program start but I
    never got that character from the buffer. So the buffer pointer was always 1 larger
    then needed. Fixed that by actually checking and proofing that the expected
    character was received.

  • Roelof,

    I apologize for the confusion caused due to the message reported in the debug console. This is a known bug in CCS 6.1.3 in that the "expected RAM usage" reported in the console is incorrect. Please see this related post.

    The workaround for CCS 6.1.3 is to look at the RAM usage in the linker map file, or CCS Memory Allocation view to get the accurate numbers.

    The bug is fixed in CCS 7.0.0 and higher so updating to a newer CCS is another solution.

  • Thanks for responding.

    I read the mentioned post and it seems, must be, the same as what I am experiencing.
    Upgrading to ccs v7 is next on my list :-)

    Thank you