• Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 4907 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.

Can't get printf to work on MSP430

Peddler
Intellectual 365 points
Other Parts Discussed in Thread: MSP430F2274

Hi, I recently started using Code Composer 4.2 for the first time.  I'm running it under Windows 7, targeting the MSP430F2274.  After two weeks of frustration I'm not making much progress.  This post is the first for several issues.

Issue: Printf won't work.  It seems to crash the linker:
<Linking>
"../lnk_msp430f2274.cmd", line 75: error: run placement fails for object
   ".stack", size 0x200 (page 0).  Available ranges:
   RAM          size: 0x400        unused: 0xac         max hole: 0xac     
"../lnk_msp430f2274.cmd", line 80: error: run placement fails for object
   ".cio", size 0x120 (page 0).  Available ranges:
   RAM          size: 0x400        unused: 0xac         max hole: 0xac     
error: errors encountered during linking; "APA-TX_firmware.out" not built

>> Compilation failure
gmake: *** [APA-TX_firmware.out] Error 1
gmake: Target `all' not remade because of errors.
Build complete for project APA-TX_firmware


sprintf only works with ints and no other variable types.  It does work when I cast an unsigned long as an int and print as an int (%d). For example, sprintf'ing using %c, %u, %ld, %lu and other format specifiers doesn't work (either prints nothing or prints "0"). 

I'm using stdio.h.  I've set the compiler switch for printf to maximum support.  It seems that perhaps printf is hogging too many resources for the MSP430 like too much RAM and/or too much stack space. printf does work with the IAR compiler.  Any suggestions other than switching to IAR?  Thanks,

- Chris

 

  • TI__Guru**** 162325 points

    Chris,

    The linker isn't crashing it is having trouble fitting the code into the available memory.  For MSP430 I would recommend using "minimal" printf support in the build options under Library Function Assumptions.  

    If I build a simple helloworld program with full printf and then with minimal printf I can see a big difference in the map files.

    Full printf Uses 23f0 in FLASH versus only 1128 for minimal printf.  

    I am going to move the post into the compiler forum so you can get more help with using printf/sprintf

     

    Regards,

    John

     

  • TI__Guru**** 173310 points

    Chris,

    As John mentioned, printf/sprintf can have large memory requirements, hence by default for MSP430 devices, we set the printf support to minimal, which supports only certain format specifiers. Please take a look at this page for more information on printf support: http://processors.wiki.ti.com/index.php/Printf_support_in_compiler

    printf also requires sufficient heap and stack space to function correctly, so you need to make sure you set these sizes accordingly in the project build options. If a call to printf fails at runtime, insufficient stack or heap space could be the reason.

    Specifically for your linker errors, there is not enough memory in RAM to fit all the sections that you have allocated to RAM. Analyzing the link map file should give you an idea of which sections are too large to fit into the available memory.

  • TI__Guru* 84285 points

    Chris35513 said:

    sprintf only works with ints and no other variable types.  It does work when I cast an unsigned long as an int and print as an int (%d). For example, sprintf'ing using %c, %u, %ld, %lu and other format specifiers doesn't work (either prints nothing or prints "0"). 

    I'm using stdio.h.

    Usually when you get the wrong value printed depending on the format specifier, it's a sign that the prototype for sprintf (in stdio.h) isn't visible, or the type of the object being passed doesn't match the format specifier.  Are you perhaps using "minimal" printf mode when sprintf fails in this way?  "Minimal" mode cannot handle the 'l' (lower case L, meaning "long") modifier for integer formats, or the "%u" decimal format, but it should be able to handle %c just fine.

    Could you post a small, compilable test case which demonstrates the problem, along with the compiler options used?