• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 1644 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.

MSP430 Code size mismatch

Kummi
Mastermind 6220 points
Other Parts Discussed in Thread: MSP-GANG, MSP430F5529

Hi,

Why does the code size used is different from CCS memory map and the programming tool
lile MSP-GANG/FET-Pro430?

For example the CCS memory allocation or memory map for the USB project(MSP430F5529)
is shown as below. 1,668+9,332 total 10,500 bytes.


Whereas when we open the .txt file in the MSP-GANG or FET-Pro430 GUI,
it shows the memory size as 10,546 bytes (46 bytes more than the CCS memory map).


In our actual project the code size difference is even bigger.

CCS memory Map-> 64,572 bytes
MSP-GANG memory size-> 64,618 bytes

Please let me know why is this difference?
You can re-produce this issue with any sample code or any device.

Best Regards
Kummi

  • 0
    TI__Guru* 78021 points
    Hi Kummi,

    I'm looking into this, and will get back to you as soon as I have more information. Please bear in mind that this one may take a little bit of time to get an answer because these are tools created by two different teams, so it may take me some time to find the difference. Thanks in advance for your patience.

    Personally, I think that the .map file in CCS is usually the best way to find the true code size so you may want to look at that (I'm going to guess that is also what the CCS memory allocation shows, but I could be mistaken).

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Guru 58965 points

    Katie Pier said:
    Personally, I think that the .map file in CCS is usually the best way to find the true code size so you may want to look at that (I'm going to guess that is also what the CCS memory allocation shows, but I could be mistaken).

    Personally, I think the 10546 bytes reported by MSP-Gang is the actual number of bytes that is needed to be downloaded into the target. You could confirm this by examine the "C1...txt" file manually. Is this file generated directly by CCS? Or is an utility program used to translate what CCS generated into this format? I cannot rule-out the possibility of "something (46 bytes) gained in the translation" ;)

  • 0
    Guru 58965 points

    Is it possible that you show us the C1_LedOnOff.txt file? Most of the lines in this file are just 16 hex numbers, you could skip over those lines and just show all the shorter lines.

  • 0 in reply to old_cow_yellow
    TI__Guru* 78021 points
    Usually you would generate the .txt file from CCS as well, it is a post-build step you can add in your project properties (hex utility). Your idea of seeing the # of lines in the file with 16 bytes and then counting the others is actually a great idea
  • 0 in reply to Katie Pier
    TI__Guru* 78021 points

    I haven't got an answer about how either of these tools calculates these values to determine the discrepancy, but I now have a theory:

    You mentioned that the difference is 46 bytes. I checked on the MSP430F5529, and I found that there are 46 bytes of used interrupt vector table on the MSP430F5529 (see www.ti.com/lit/gpn/msp430f5529 p. 52 Table 6-1 Interrupt Sources, Flags, and Vectors, you can see that the IVT goes from 0xFFD2-0xFFFF on this device, or 46 bytes of used entries). This makes me suspect that CCS does not count the IVT in its memory allocation calculation, but the Fet-Pro430 and MSP-GANG both do. I'm working to get confirmation. Thanks so much for posting!

    Regards,
    Katie

  • 0 in reply to Katie Pier
    TI__Guru* 78021 points
    Hi Kummi,

    Per Chester's suggestion here e2e.ti.com/.../1933908, you can view the interrupt vectors in the memory allocation view by clicking the white triangle and selecting Show > All Ranges. You need to include the interrupt vector sections that are allocated in your calculation - that should make up your missing 46 bytes I believe. Let me know if that resolves your question, and thanks for posting!

    Regards,
    Katie

**Attention** This is a public forum