How much free RAM do I have?

[laszlomonda]

Hi All,

I attached uhk-left.elf generated by the "left" project of our open source Ultimate Hacking Keyboard firmare repo. I'd like to see how much free RAM do I have, and the results of the arm-none-eabi-size and nm utilities seem to contradict each other.

$ arm-none-eabi-size --format=berkeley "uhk-left.elf"

text data bss dec hex filename
3104 416 1184 4704 1260 uhk-left.elf

According to my understanding and based on the above, data (416) + bss (1184) = 1600 bytes are being used out of the 2K RAM of the KL03.

Now let's compare this with the output of the nm utility:

$ nm --print-size --size-sort uhk-left.elf
200000b6 00000001 b byteIn.4509
200001d8 00000001 b prevEvent.4488
200001cc 00000001 b rxMessagePos.4489
000006e5 00000002 W __aeabi_idiv0
000006e5 00000002 W __aeabi_ldiv0
200001e0 00000002 b crc16data.4497
00000f0d 00000002 T _exit
00000541 00000004 W ADC0_IRQHandler
00000541 00000004 W CMP0_IRQHandler
00000541 00000004 W DefaultISR
00000541 00000004 W FTFA_IRQHandler
00000f1c 00000004 T _global_impure_ptr
00000549 00000004 W HardFault_Handler
00000559 00000004 W I2C0_IRQHandler
200001d0 00000004 b I2C_Watchdog.4507
200001c8 00000004 b I2C_WatchdogInnerCounter.4487
200001d4 00000004 b I2C_WatchdogOuterCounter.4506
00000541 00000004 W LLWU_IRQHandler
00000541 00000004 W LPUART0_DriverIRQHandler
00000561 00000004 W LPUART0_IRQHandler
00000545 00000004 W NMI_Handler
00000551 00000004 W PendSV_Handler
00000541 00000004 W PMC_IRQHandler
00000541 00000004 W PORTA_IRQHandler
00000541 00000004 W PORTB_IRQHandler
200001dc 00000004 b prevWatchdogCounter.4128.4486
00000541 00000004 W Reserved16_IRQHandler
00000541 00000004 W Reserved17_IRQHandler
00000541 00000004 W Reserved18_IRQHandler
00000541 00000004 W Reserved19_IRQHandler
00000541 00000004 W Reserved20_IRQHandler
00000541 00000004 W Reserved25_IRQHandler
00000541 00000004 W Reserved27_IRQHandler
00000541 00000004 W Reserved29_IRQHandler
00000541 00000004 W Reserved30_IRQHandler
00000541 00000004 W Reserved35_IRQHandler
00000541 00000004 W Reserved38_IRQHandler
00000541 00000004 W Reserved39_IRQHandler
00000541 00000004 W Reserved40_IRQHandler
00000541 00000004 W Reserved41_IRQHandler
00000541 00000004 W Reserved42_IRQHandler
00000541 00000004 W Reserved43_IRQHandler
00000541 00000004 W Reserved45_IRQHandler
00000541 00000004 W RTC_IRQHandler
00000541 00000004 W RTC_Seconds_IRQHandler
200001bc 00000004 b s_i2cHandle.5355.4492
200001c0 00000004 b s_i2cMasterIsr.5350.4498
200001c4 00000004 b s_i2cSlaveIsr.5352.4490
00000541 00000004 W SPI0_DriverIRQHandler
0000055d 00000004 W SPI0_IRQHandler
0000054d 00000004 W SVC_Handler
1ffffec0 00000004 d SystemCoreClock.4485
00000555 00000004 W SysTick_Handler
00000541 00000004 W TPM0_IRQHandler
00000541 00000004 W TPM1_IRQHandler
00000f10 00000008 t lircFreqs.4791.4918.4510
00000efd 00000010 T memset
000006d1 00000012 T __aeabi_idivmod
00000611 00000012 T __aeabi_uidivmod
000003c0 00000020 R BootloaderConfig
00000e61 00000024 T SystemInit
00000895 0000002c t CLOCK_GetLircClkFreq.4841.4480
000008c1 0000002c t CLOCK_GetOutClkFreq.4476
00000e85 0000002c T exit
00000a55 00000034 T I2C0_DriverIRQHandler
00000eb1 0000004c T __libc_init_array
1ffffe00 00000050 d __compound_literal.1.4555.4495
000004e9 00000058 W Reset_Handler
1fffff34 00000060 d impure_data
1ffffe50 00000070 d __compound_literal.0.4554.4494
1ffffec4 00000070 d keyMatrix.4493
00000df1 00000070 T LPTMR0_IRQHandler
00000589 00000088 T __udivsi3
00000625 000000ac T __divsi3
00000000 000000c0 R __isr_vector
1fffffb4 00000102 b rxMessage.4508
200000b7 00000102 b txMessage.4496
000008ed 00000168 t i2cSlaveCallback.4289.4113
000006e9 000001ac t I2C_SlaveTransferHandleIRQ.4216
00000a89 00000368 T main

According to my knowledge the "b" and "d" records are relevant for RAM allocation, so I computed these records by executing the following on Linux:

$ nm --print-size --size-sort uhk-left.elf | egrep '^[0-9a-f]{8} [0-9a-f]{8} [bd]' | awk '{print $2}' | awk '{print "0x" $0}' | awk '{s+=strtonum($1)} END {print s}'
953

1600 vs 953 bytes are quite a difference. Would any of you explain which is right and why the two values don't match?

Thank you very much in advance!

- Laci

Original Attachment has been moved to: uhk-left.map.zip

Original Attachment has been moved to: uhk-left.elf.zip

[mjbcswitzerland]

Laci

Take a look in the map file that is generated. Search for the highest address in SRAM and this will be the value that you need.

Generally you will find
.data
.bss

.non_init
.heap
.stack

and .stack will be the highest address.

If you don't use heap, make sure that it is 0 in length (to save wasting space).
Often the size of stack needs to be set in the linker script but I set 0 and just use the remaining SRAM for the stack. In any case, you must also know how much stack your application uses in its worst run-time case to be sure that you have adequate memory.

Regards

Mark

http://www.utasker.com/kinetis.html
http://www.utasker.com/kinetis/FRDM-KL03Z.html

[laszlomonda]

Hi Mark,

I also attached is the uhk-left.map file above.

It seems to me that I'm using heap and it occupies 0x204 bytes. Is this correct? When should I use heap?

0x20000600 seems to be the highest address. Is this correct? Where does this leave us regarding RAM consumption?

Thanks so much!

- Laci

[mjbcswitzerland]

Laci

You have 0x204 [516] bytes of heap and the stack area is defined to use the remaining space (0x20000600 - 0x200003e8) 0x218 [536].
I don't know whether you use heap (malloc() etc.) or not - if not, you can set HEAP_SIZE in your linker script to 0 to save this space.
Your variables occupy 0x1ffffe00 ..0x200001e4, which is 0x3e4 [996] bytes

996 variables + 516 heap + 536 stack = 2k exactly

The SRAM consumption also depends on the stack use. This means the local variables and buffers used by each subroutine in the call stack and interrupts. If you fill the stack area with a pattern before the code starts you can get a good idea of its utilisation by seeing which is the lowest address in the stack area where the pattern has been overwritten by the stack use.

Since you have a small chip, with only 2k of SRAM you should be consistently monitoring these details as the project evolves to be sure that there is adequate stack margin to ensure safe operation.

Regards

Mark

[laszlomonda]

Thanks so much for the further explanation, Mark!

Given that I don't utilize malloc() at all, setting the heap size to zero would definitely make a lot of sense for me. I found HEAP_SIZE in MKL03Z32xxx4_flash.ld and MKL03Z32xxx4_ram.ld within the KSDK. It'd be nice to modify the heap without touching the KSDK files. I can see that HEAP_SIZE depends on __heap_size__. Is there any way to change this from my project?

Thanks again!

- Laci

[mjbcswitzerland]

Laci

I don't work with KSDK so someone else will need to give an authoritative answer, however the heap size value is probably used by a library and is therefore needed. Since it is defined in a linker script file (nasty way in my opinion since it makes the file project-specific) there may be no other option but to edit it there and make the file project-specific.

Regards

Mark

[BlackNight · Accepted solution]

This article describes how to set the heap and stack size in the GNU linker file without changing the linker file itself:

https://mcuoneclipse.com/2016/04/17/changing-heap-and-stack-size-for-nxp-kinetis-sdk-v2-0-gcc-projec...

I hope this helps,

Erich