.bss assigned to rts430.lib

You are calling some C I/O functions such as fopen and fprintf.  You can get a general idea of how much is involved with these functions here http://processors.wiki.ti.com/index.php/Tips_for_using_printf#Getting_C_I.2FO_working_.2F_Troubleshooting .  The build option --printf_support for reducing the footprint of the C I/O functions is described here http://processors.wiki.ti.com/index.php/Printf_support_in_compiler .  As you will see, the default for the MSP430 compiler is --printf_support=minimal, which gives you the smallest memory footprint.  That said, it is probably worth your time to check and be sure you are building with --printf_support=minimal.  Your only other option is probably the one used by the other "software set": don't call the C I/O functions at all.

Thanks and regards,

-George

I tried the --printf_support=minimal option and it did not accept the option.  I am using Version: CCE v3.1   Build: 3.2.3.6.4 and I have an MSP430F149 micro.

<Linking>
>> WARNING: invalid linker option --printf_support=minimal (ignored)

So why would compiling using CEE be different from compiling with gcc for the C I/O functions memory usage?

Thanks

Tom

--printf_support is a compiler option, not a linker option.  On a command line that means it must come before the -z in the cl430 command.  I don't know how this works in CCS.

Tom,

I currently don't have CCE 3.2.3.6.4 installed but in CCE there are a couple of steps you need to take to make it recognize this option, and I'll try to talk you through them.

First check that the version of compiler tools in that release is 3.0.x or higher. Go to C:\Program Files\Texas Instruments\CC Essentials v3.1\tools\compiler\MSP430\bin, right-click on cl430.exe, Properties->Version tab and verify the version.

If the version supports the option, it should appear under Project Properties->C/C++ Build->MSP430 Compiler->Library Function Assumptions. Make the --printf_support selection there and save. This adds the compiler option to the build but there is still an issue because prior to CCS 4.1 the option was not correctly being passed to the linker.

To work around this, highlight Project Properties->C/C++ Build->MSP430 Linker. On the right pane, change Command to:
"${MSP430_CG_ROOT}/bin/cl430" --printf_support=minimal -z

This should allow the option to be passed correctly. After the build please check the link map file to ensure that the correct version of printf is linked in. Please also check http://processors.wiki.ti.com/index.php/Printf_support_in_compiler for related information.

1ST PROJECT

Unfortunately the printf minimal option did not reduce the space so I gave up and temporarily took out the printf statements to move on.   How do I check the link map file to ensure that the correct version of printf is linked in?

2ND PROJECT

Now I have another project I am trying to transfer to CCE and I ran out of Flash and RAM again.  So again I removed all print statements and this time I cannot reduce the size of rts430.lib.  What is the best way to find what the code is using in these libraries?

1ST PROJECT - with printf statements

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.bss       0    00000000    00000830     FAILED TO ALLOCATE
.const     0    00000000    00002d50     FAILED TO ALLOCATE
.pinit     0    00001100    00000000     UNINITIALIZED

.cio       0    00000200    00000120     UNINITIALIZED
                  00000200    00000120     rts430.lib : trgmsg.obj (.cio)     --  goes away without printf statements

.sysmem    0    00000320    00000004     UNINITIALIZED
                  00000320    00000004     rts430.lib : memory.obj (.sysmem)

.stack     0    00000980    00000080     UNINITIALIZED
                  00000980    00000002     rts430.lib : boot.obj (.stack)
                  00000982    0000007e     --HOLE--

1ST PROJECT - without printf statement

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.pinit     0    00001100    00000000     UNINITIALIZED

.bss       0    00000200    0000060c     UNINITIALIZED
                  00000200    000004e6     common.obj (.bss)
                  000006e6    00000087     main.obj (.bss)
                  0000076d    00000001     --HOLE--
                  0000076e    0000004c     radio.obj (.bss)
                  000007ba    00000038     usart.obj (.bss)
                  000007f2    00000007     util.obj (.bss)
                  000007f9    00000001     --HOLE--
                  000007fa    00000005     interrupt.obj (.bss)
                  000007ff    00000001     --HOLE--
                  00000800    00000004     rts430.lib : _lock.obj (.bss)
                  00000804    00000004                : exit.obj (.bss)
                  00000808    00000004                : rand.obj (.bss)

.stack     0    00000980    00000080     UNINITIALIZED
                  00000980    00000002     rts430.lib : boot.obj (.stack)
                  00000982    0000007e     --HOLE--

2ND PROJECT - without printf statements

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.stack     0    00000000    00000080     FAILED TO ALLOCATE
.pinit     0    00001100    00000000     UNINITIALIZED

.bss       0    00000200    000006c6     UNINITIALIZED
                  00000200    00000410     common.obj (.bss)
                  00000610    0000011a     rts430.lib : defs.obj (.bss)
                  0000072a    00000088                : trgdrv.obj (.bss)
                  000007b2    00000078                : lowlev.obj (.bss)
                  0000082a    00000028     usart.obj (.bss)
                  00000852    00000028     user.obj (.bss)
                  0000087a    00000016     wiegand.obj (.bss)
                  00000890    00000010     prox.obj (.bss)
                  000008a0    00000009     main.obj (.bss)
                  000008a9    00000001     memory.obj (.bss)
                  000008aa    00000008     rts430.lib : memory.obj (.bss)
                  000008b2    00000004                : _lock.obj (.bss)
                  000008b6    00000004                : exit.obj (.bss)
                  000008ba    00000004                : rand.obj (.bss)
                  000008be    00000003     interrupt.obj (.bss)
                  000008c1    00000003     util.obj (.bss)
                  000008c4    00000002     rts430.lib : fopen.obj (.bss)

Tom Schuster said:

How do I check the link map file to ensure that the correct version of printf is linked in?

In the link map file you can search for _printfi and see which .obj files the sections are coming from (_printfi.obj or _printfi_min.obj etc depending on the level of printf support selected for the build).

Tom Schuster said:

What is the best way to find what the code is using in these libraries?

 Looking at your map file it looks like the larger portion of .bss is coming from defs.obj, trgdrv.obj and lowlev.obj. defs.c defines some data structures declared in stdio.h. trgdrv.c contains routines for sending commands to the host (like HOSTopen/HOSTclose) and lowlev.c contains low level I/O routines. To see what these or other runtime files actually do, you may extract the runtime sources from rtssrc.zip and take a look at the code.

What does it mean if I see both _printfi_min.obj and _printfi.obj?

rts430.lib : _printfi_min.obj (.text:_setfield)
rts430.lib : _printfi_min.obj (.text:_printfi_minimal)
rts430.lib : lsr32.obj (.text)
           : trgdrv.obj (.text:HOSTrename)
           : _printfi_min.obj (.text:_ltostr)
rts430.lib : _printfi_min.obj (.text:_pproc_diouxp)
           : div32u.obj (.text)
           : lowlev.obj (.text:getdevice)
           : lowlev.obj (.text:lseek)
rts430.lib : lowlev.obj (.text:write)
           : _printfi_min.obj (.text:_pproc_str)
           : _printfi_min.obj (.text:_getarg_diouxp)
rts430.lib : _printfi_min.obj (.text:_div)
rts430.lib : mult32_hw.obj (.text)
           : trgmsg.obj (.text:writemsg)
           : printf.obj (.text:printf)
           : trgmsg.obj (.text:readmsg)
           : asr16.obj (.text)
           : div16s.obj (.text)
           : lsl16.obj (.text)
rts430.lib : printf.obj (.text:_outc)          
rts430.lib : printf.obj (.text:_outs)
           : pre_init.obj (.text:_system_pre_init)
           : exit.obj (.text:abort)
           : remove.obj (.text:remove)

I am still having trouble finding what I am using in defs, trgdrv, and lowlev.  How do you remove the rts.lib from the project?  I would like to try to manually add the files I need.

Thanks

Tom

Tom Schuster said:

How do you remove the rts.lib from the project?  I would like to try to manually add the files I need.

That's a bad idea.  Manually adding the RTS files you need is error prone and difficult to maintain over time.  

It appears that even the printf minimal memory footprint is too much for your system.  Try this.  Instead of calling printf, call putchar (or fputc) instead.  Sure, your code won't work, but this is a build time only experiment.  Does it all fit then?  I suspect it won't.  If I'm right, then the C I/O functionality in the RTS library, even in its most memory conservative configuration, simply takes up more memory than your system can support.  At that point, you've gone outside the bounds at which we compiler experts can help you.

Thanks and regards,

-George

You are right even with a call to the standard putchar the extra objects take too much RAM.

00000602 0000011a rts430.lib : defs.obj (.bss)
0000071c 00000088 : trgdrv.obj (.bss)
000007a4 00000078 : lowlev.obj (.bss)

int putchar(int c)
{
   usart1Putch((char)c);
   return(c);
}

sprintf(tempout,"%02d",tempid[(HASH_IND_LEN - 1)]);

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  RAM                   00000200   00000800  00000511  000002ef  RWIX

But as soon as I add a printf the extra objects are included.  Is there a manual way I can add in just the supporting printf functions?

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  RAM                   00000200   00000800  000007da  00000026  RWIX

Thanks

Tom

Tom Schuster said:

Is there a manual way I can add in just the supporting printf functions?

Theoretically, yes.  But it would make no effective difference.  For the code to execute printf, you need all that code from trgdrv.obj and lowlev.obj. But all that code doesn't fit in your system.  These are the choices I see: Either re-write your code to not use printf, or add memory to the system.  We compiler experts can't help you with either of those.

A side point I should have mentioned earlier ... Are you aware the C I/O functions work only when you are executing under CCS?  It is possible to make them work outside of CCS.  Details on that here http://processors.wiki.ti.com/index.php/Tips_for_using_printf#Using_printf.28.29_to_output_to_a_user-defined_device .  

Thanks and regards,

-George

I am moving forward with sending single characters to usart1 using a re-directed putchar where needed.  I can see this data fine in hyperterm running outside CCS. 

So is there a simple reason why our privious code fit with printf support when compiling with the mspgcc compiler?

int putchar(int c)
{
   usart1Putch((char)c);
   return(c);
}

Thanks

Tom

Tom Schuster said:

So is there a simple reason why our privious code fit with printf support when compiling with the mspgcc compiler?

I don't know.

-George

Tom Schuster said:

So is there a simple reason why our privious code fit with printf support when compiling with the mspgcc compiler?

Just speculating...

Assuming the mspgcc compiler is doing formatted IO (printf and friends) to a host environment (like a Windows PC), it is possible that the formatting (interpreting the format string, translating the values to output strings, etc) is implemented on the host side rather than being done by target (MSP) code.  That would greatly reduce the amount of runtime support loaded on to the MSP.  The TI runtime does all the formatting on the MSP with only the final, formatted string being sent back to the host.

Just to clear up a point from earlier in this thread...

The excerpt you sent from the linker's map file does not appear to include code from both _printfi_min.obj and _printfi.obj.  Perhaps you were mistaking the code from printf.obj for _printfi.obj. 

You could end up with both _printfi.obj and _printfi_min in the .out file if the link input included multiple files that call printf but which were compiled with different settings of the --printf_support option.

Tom Schuster said:

What does it mean if I see both _printfi_min.obj and _printfi.obj?

rts430.lib : _printfi_min.obj (.text:_setfield)
rts430.lib : _printfi_min.obj (.text:_printfi_minimal)
rts430.lib : lsr32.obj (.text)
           : trgdrv.obj (.text:HOSTrename)
           : _printfi_min.obj (.text:_ltostr)
rts430.lib : _printfi_min.obj (.text:_pproc_diouxp)
           : div32u.obj (.text)
           : lowlev.obj (.text:getdevice)
           : lowlev.obj (.text:lseek)
rts430.lib : lowlev.obj (.text:write)
           : _printfi_min.obj (.text:_pproc_str)
           : _printfi_min.obj (.text:_getarg_diouxp)
rts430.lib : _printfi_min.obj (.text:_div)
rts430.lib : mult32_hw.obj (.text)
           : trgmsg.obj (.text:writemsg)
           : printf.obj (.text:printf)
           : trgmsg.obj (.text:readmsg)
           : asr16.obj (.text)
           : div16s.obj (.text)
           : lsl16.obj (.text)
rts430.lib : printf.obj (.text:_outc)          
rts430.lib : printf.obj (.text:_outs)
           : pre_init.obj (.text:_system_pre_init)
           : exit.obj (.text:abort)
           : remove.obj (.text:remove)