FreeRTOS footprint on MicroBlaze

ema083 wrote on Tuesday, March 11, 2008:

Hi everybody,

I’m using FreeRTOS on a MicroBlaze; I was surprised because the OS footprint is not 3-4 KB but, on my architecture, is about 12 KB.

Is the footprint supposed to be like that? Do you have any suggestions on how to shrink it? (I’ve already set the parameters in freeRTOSConfig.h)…

With thanks in anticipation,

davedoors wrote on Wednesday, March 12, 2008:

I don’t know about Microblaze but that does not sound right at all. How are you obtaining the footprint size? That is, where are you getting the 12K number from?

ema083 wrote on Wednesday, March 12, 2008:


here is the output when I compile my project:

mb-gcc -O2 code/main.c code/Source/list.c code/Source/queue.c code/Source/tasks.c code/Source/portable/MemMang/heap_1.c code/Source/portable/GCC/MicroBlaze/port.c code/Source/portable/GCC/MicroBlaze/portasm.s code/serial.c  -o MB_1/executable.elf
    -mno-xl-soft-mul -mcpu=v4.00.a  -Wl,-T -Wl,Proj_MB_1_linker_script.ld     -I./mb_1/include/  -Icode/ -Icode/Source/include/   -I. -I./code/Common/include -I./code/Source/include -I./code/Source/portable/GCC/MicroBlaze  -L./mb_1/lib/ 

mb-size MB_1/executable.elf
   text       data        bss        dec        hex    filename
  12136        122      19720      31978       7cea    MB_1/executable.elf

I’m getting the footprint size from the “text” value… I hope this is the right way to get it…

rtel wrote on Wednesday, March 12, 2008:

Yes this is a valid way of getting the size but the 12K for the kernel is very improbable.  Can you look in the map file to see which module is taking up the text, I would be very surprised if it were anything to do with the kernel.

Is you main.c using any GCC libraries?  In particular anything to do with sprintf/printf/scanf?  This can bring LOTS of very inefficient GCC library code into your build.


ema083 wrote on Thursday, March 13, 2008:

My main.c is the one included in the Demo, from which I erased the demo function calls; so I’m sure I’ve not included other GCC functions. The part of the map file dealing with text is listed below (I’ve cut some lines to don’t take up too much space). If you please can help me figure out what’s wrong, I’ll be very glad… I’m not an expert on this topic…

.text    0x00000050    _start1
          0x0000006c    exit
          0x000000e8    _crtinit
.text    0x00000170    main
.text    0x000001d4    vListInsertEnd
          0x000020e8    xSerialPortInitMinimal
.text    0x00002388    _exception_handler
.text    0x00002390    _program_clean
.text    0x00002398    _program_init
.text    0x000023a0    _hw_exception_handler
.text    0x000023a4    microblaze_disable_interrupts
.text    0x000023c4    microblaze_enable_interrupts
.text    0x00002478    microblaze_register_handler
          0x000023e4    _interrupt_handler
          0x000023e4    __interrupt_handler
.text    0x00002910    XTmrCtr_Reset
          0x00002bb4    XIntc_SetIntrSvcOption
.text    0x00002c7     XNullHandler
          0x00002c34    XAssert
          0x00002c68    XAssertSetCallback
.text    0x00002c80    memcpy
.text    0x00002d38    memset
.text    0x00002de0    strncpy
.text    0x00002f2c    0x3c /cygdrive/c/EDK/gnu/microblaze/nt/bin/…/lib/gcc/microblaze/3.4.1/m/crtend.o

Best regards

rtel wrote on Thursday, March 13, 2008:

Could you send me the .map file to r [dot] barry _at_


rtel wrote on Saturday, March 15, 2008:

In the map file there is:

2888 bytes for tasks.c
2748 bytes for queue.c
268 bytes for list.c
1000 bytes for port.c

Total for the kernel is then 6.9K which is the largest I have ever seen.  This must be something specific to the Microblaze architecture or instruction set inefficiencies.  I should turn on the optimiser and remove unused symbols, and see what it comes down to.

You could remove quite a lot from port.c by removing the code that fills the registers with known values.  You could also make functions out of some of the inline code.

In addition you have:

1548 bytes for libxil.a.
732 bytes for the USRT driver.
416 bytes for the Xilinx interrupt handler code.


ema083 wrote on Sunday, March 16, 2008:

Thank you very much for your help!

I’ll try and see if I can shrink it a bit with your suggestions.

Thanks again, best regards,