• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 83 subscribers
  • Views 914 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.

Static code analysis tools

Paolo Benini
Intellectual 485 points

Other Parts Discussed in Thread: TMS320F28335, TMS320F2812

Hello,

I'm currently working on TMS320F2812/TMS320F28335 DSPs and still developing/debugging through Code Composer Studio v4 (although my company has already purchased the new v5).

Our programming language is "C" and I was wondering if TI provides any tool for static code analysis. In particular I would be interested in the following:

1) How much code memory and which type (linker section) is used by each "C" function and each linked "C" module;

2) How much RAM (both internal and external) and which type (linker section) is used by each function/module;

3) Function calling tree

I know some kind of information can be partially retrieved from the linker memory map but it is way too dispersed and unorganized. I need a flexible tool which is capable of automatically extracting, ordering and presenting this information in a readable format.

Any help/suggestion would be greatly appreciated.

Paolo

  • 0
    Guru 14640 points

    Paolo:

    The first two can be accomplished by examining the .map file generated by the linker.

    I have seen the third item done, but you may need to pay for the tool. Doxygen will give you graphical call tree info.

  • 0 in reply to Todd Anderson78572
    Intellectual 485 points

    Sorry but there's something not quite clear to me.

    Apparently the map file is not very reliable.

    Please have a look at those two memory maps. The second one contains 6 more variables declared (and allocated) in "RAML4567" section. Nevertheless, both the "used" and the "unused" size in the memory summary are exactly the same! How could that be???

    The added variables are:

    1) HWDIO_u32Paolo_override (32 bits)

    2) HWDIO_u32Paolo1_override (32 bits)

    3) HWDIO_u32Paolo2_override (32 bits)

    4) HWDIO_u32Paolo3_override (32 bits)

    5) HWDIO_u32Paolo4_override (32 bits)

    6) HWDIO_u32Paolo5_override (32 bits)

    Attached also the linker command file.

    Thanks a lot.

    Paolo

    TiForum.zip
  • 0 in reply to Paolo Benini
    Mastermind 7585 points

    RAM4567 wil lbe used for global variables. If you did declare your 6 new variables as local variables, then they will be allocated into stack. In this case the ebss-section will not change,

     

  • 0 in reply to Frank Bormann
    Intellectual 485 points

    I perfectly know the difference between a global and a local variable, thanks!

    They are all global variables, that's the problem. The map file is simply wrong. How can you possibly explain that declaring 6 more global variables did not cause the "used" size of RAM4567 to increase?

    ***** Added Comments *****

    I have an idea on how it works, just need someone to confirm that. I believe the linker is allocating data using 64-word pages; whenever it cannot fit a new global variable into an existing page, it creates a new 64-word page or more depending on the size but always a multiple of 64. The real "unused" space is not counted in the section's summary.

    To be more precise, I'll make an example: let's suppose the linker has allocated a global array of 100 32-bit elements in 4 new 64-word pages = 256 words (I actually verified that) which would be the minimum multiple of 64 containing the 200 words. If I declare a new 32-bit variable and the linker decides to allocate it in one of those already existing pages, the memory summer would not change because those pages had been actually allocated previously. If this is true (could not find it in any document), I still consider the memory map wrong. The "unused" field should represent the real available space, while it doesn't.

    Paolo