I’m using the default template design RISC-V_Renode_Emulator_SoftConsole of FreeRTOS to build with default FreeRTOSConfig.h constants. Here The .bss section consumes 28KBytes of memory. Why is it so?
You can check the map file generated by linker to see what’s inside the bss.
The linker has on option (e.g. -map for GNU linker) to generate it along with the elf file.
If you are using heap_1, heap_2, heap_4 or heap_5 then the heap memory comes from a statically allocated array - so you are probably seeing all the unused heap.
@Hartmut Schaefer thanks for your reply.
I have checked my application map file. I’m using heap_4.c memory management portable layer. Does the uninitialized heap memory size count on .bss section?
Please see my map file for .bss section.
.bss 0x0000000080004f00 0x46130
0x0000000080004f00 __bss_start = .
(.shbss)
(.bss .bss. .gnu.linkonce.b.)
.bss.ucHeap 0x0000000080004f00 0x46000 ./FreeRTOS_Source/portable/MemMang/heap_4.o
.bss.pxReadyTasksLists
0x000000008004af00 0x64 ./FreeRTOS_Source/tasks.o
.bss.xDelayedTaskList1
0x000000008004af64 0x14 ./FreeRTOS_Source/tasks.o
.bss.xDelayedTaskList2
0x000000008004af78 0x14 ./FreeRTOS_Source/tasks.o
.bss.xPendingReadyList
0x000000008004af8c 0x14 ./FreeRTOS_Source/tasks.o
.bss.xTasksWaitingTermination
0x000000008004afa0 0x14 ./FreeRTOS_Source/tasks.o
.bss.xSuspendedTaskList
0x000000008004afb4 0x14 ./FreeRTOS_Source/tasks.o
.bss.xActiveTimerList1
0x000000008004afc8 0x14 ./FreeRTOS_Source/timers.o
.bss.xActiveTimerList2
0x000000008004afdc 0x14 ./FreeRTOS_Source/timers.o
*(COMMON)
COMMON 0x000000008004aff0 0x40 ./FreeRTOS_Source/queue.o
0x000000008004aff0 xQueueRegistry
0x000000008004b030 . = ALIGN (0x10)
0x000000008004b030 __bss_end = .
0x000000008004b030 _end = .
.heap 0x000000008004b030 0x10
0x000000008004b030 __heap_start = .
0x000000008004b034 . = (. + HEAP_SIZE)
fill 0x000000008004b030 0x4
0x000000008004b034 __heap_end = .
0x000000008004b040 . = ALIGN (0x10)
fill 0x000000008004b034 0xc
0x000000008004b034 _heap_end = __heap_end
.stack 0x000000008004b040 0x800
0x000000008004b040 __stack_bottom = .
0x000000008004b840 . = (. + STACK_SIZE)
fill 0x000000008004b040 0x800
0x000000008004b840 __stack_top = .
0x000000008004b840 _sp = .
0x000000008004b840 __freertos_irq_stack_top = .
OUTPUT(RTOSDemo.elf elf32-littleriscv)
How can reduce .bss section in my design?
That’s the FreeRTOS heap. Therefore bss has its size.
However, bss shouldn’t matter. It’s uninitialized data just zeroed during init of the C-runtime environment. Why do you care ?
Or, if the problem is you are out of memory, make the heap smaller.
As explained by @hs2, it is the FreeRTOS heap which is consuming most of bss. Since you are using heap_4, you can control its size using configTOTAL_HEAP_SIZE in your FreeRTOSConfig.h: FreeRTOS-Kernel/heap_4.c at main · FreeRTOS/FreeRTOS-Kernel · GitHub
You can try to reduce the heap by reducing the value of configTOTAL_HEAP_SIZE.
Thanks.
@Hartmut Schaefer .bss section goes to RAM and this much memory is not available in the target hardware. so that I’m not able to accommodate my code in the target platform. That’s why I’m concern about .bss section.
As I said, make the heap smaller, if you don’t have that much RAM, hopefully your program can live with a smaller heap, or it might not be able to run on this platform.
Hi,
Could we have the ucHeap allocated in sections other than .bss?
We are using STM32H series microcontroller, where different types of RAM’s available. We would like to have the .bss segment to be in DTCM RAM as it provides the ECC single bit error correction feature. This RAM is about 128KB.
ucHEAP (size of96K ) being part of .bss along with our application requirement can’t be accommodated in DTCM RAM. But we can accommodate the heap in other RAM’s.
Moving out of .bss section would make the ucHEAP uninitialized. Would that cause any problem at FreeRTOS level?
There is almost certainly a compiler extension to control what segment a variable is being place in.
Yes there is.
But, my question is, if it is put in any segment other than .bss, it won’t be initialized. So I was wondering this would cause any problem
The simplest way to answer that question is look at the code. I think all the various implementations check one of the pointers used to manage the heap for being NULL, so THAT variable needs to be cleared, the heap itself gets setup when that variable is detected NULL, and I don’t think anything assumes it has been pre cleared.
I don’t think that the raw heap memory block(s) are assumed being zeroed.
When in doubt just see the source of your choosen heap implementation heap_<N>.c.
Hello,
you are free to manually clear the segment at sysmte startup if you want to be on the safe side (the zeroing of .bss is one of the very first code fragments executed out of reset, so you can simp,ly clone it for your custom segment).
The other way around is more fun, though: Instead of zeroing out the segment, fill it with, say, 0xfeef or something the like. If anything breaks, it means there is code somewhere that makes assumptions about initialized memory. In a few cases that is valid (for example, globals are normally expected to be in .bss and therefore clear upon first use), but for a block of heap memory, it shouldn’t make a difference what is in the memory - the heap manager should definitely make sure not to leave anything uninitialized, and heap manager clients (eg code fragments using malloc()) must not rely on zeroed heap blocks - they must use calloc() if they want defined memory).
Thus, one can use non-zeroed memory of a test bed for QA.
If there is anything relying on the heap being cleared to zero at startup it is definitely not intentional! So if you find that to be the case, then please let us know.
As others have already answered, this should not be a problem. In addition, if you want to use more than one memory regions for heap, you can use heap_5. Here is an example: https://github.com/aws/amazon-freertos/blob/main/vendors/st/boards/stm32l475_discovery/aws_demos/application_code/main.c#L569
Thanks.
Thank You every one for your answers. Yes, I do understand and expect all the code and libraries using the heap should NOT assume that it’s initialized. But thought it would be good to get others views and experiences if at all they have seen that kind of dependencies. Specially when the memory was seen part of .bss segment.
We will continue our testing and if we come across any other observations will update here. Again thank you all for your responses and insights.