AnsweredAssumed Answered

2k of RAM usage unaccounted for on my M0

Question asked by Thanh Truong on Nov 29, 2016
Latest reply on Nov 30, 2016 by Alice_Yang

There appears to be about 2k of RAM used on my M0 that I can't account for.  I notice this when the stack appear to be growing into the heap it cause the program to freeze.  I currently only have 24 bytes allocated in the heap and there should be about 2.3k available for the stack and the heap.

 

Here's the compiler summary:

Invoking: Cross ARM GNU Create Flash Image
arm-none-eabi-objcopy -O binary "project.elf"  "project.bin"
Finished building: project.bin

Invoking: Cross ARM GNU Print Size
arm-none-eabi-size --format=berkeley --totals "project.elf"
   text       data        bss        dec        hex    filename
  85152       1452      12256      98860      1822c    project.elf
  85152       1452      12256      98860      1822c    (TOTALS)
Finished building: project.siz

 

Reading the EFL file appear to agree with this:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interrupts       PROGBITS        00006000 006000 0000c0 00   A  0   0  4
  [ 2] .sw_info          PROGBITS        00006380 006380 000080 00   A  0   0  4
  [ 3] .cfmprotect       PROGBITS        00006400 006400 000010 00   A  0   0  1
  [ 4] .text             PROGBITS        00006410 006410 00eac8 00  AX  0   0  8
  [ 5] .init_array       INIT_ARRAY      00014ed8 014ed8 000004 00  WA  0   0  4
  [ 6] .fini_array       FINI_ARRAY      00014edc 014edc 000004 00  WA  0   0  4
  [ 7] .data             PROGBITS        1ffff000 017000 00052c 00  WA  0   0  4
  [ 8] .bss              NOBITS          1ffff52c 01752c 0010d4 00  WA  0   0  4
  [ 9] .romp             PROGBITS        20000600 018600 000018 00  WA  0   0  1
  [10] ._user_heap_stack NOBITS          20000618 018618 000400 00  WA  0   0  1
  [11] .ARM.attributes   ARM_ATTRIBUTES  00000000 018618 000028 00      0   0  1
  [12] .debug_info       PROGBITS        00000000 018640 01d66a 00      0   0  1
  [13] .debug_abbrev     PROGBITS        00000000 035caa 006c52 00      0   0  1
  [14] .debug_loc        PROGBITS        00000000 03c8fc 00e0bc 00      0   0  1
  [15] .debug_aranges    PROGBITS        00000000 04a9b8 0011f8 00      0   0  1
  [16] .debug_ranges     PROGBITS        00000000 04bbb0 001590 00      0   0  1
  [17] .debug_line       PROGBITS        00000000 04d140 009e0d 00      0   0  1
  [18] .debug_str        PROGBITS        00000000 056f4d 00652d 01  MS  0   0  1
  [19] .comment          PROGBITS        00000000 05d47a 000070 01  MS  0   0  1
  [20] .debug_frame      PROGBITS        00000000 05d4ec 003d18 00      0   0  4
  [21] .stab             PROGBITS        00000000 061204 00009c 0c     22   0  4
  [22] .stabstr          STRTAB          00000000 0612a0 0001c7 00      0   0  1
  [23] .shstrtab         STRTAB          00000000 061467 00010b 00      0   0  1
  [24] .symtab           SYMTAB          00000000 061984 007fa0 10     25 1528  4
  [25] .strtab           STRTAB          00000000 069924 00368e 00      0   0  1
Key to Flags:

 

I wrote a section of code to allow memory in the heap using malloc and print out it's location, I got the following:

The last number is the iteration.  I allocate 4 bytes at a time, and it looks like it takes up at least 8-16 bytes in the heap.  The excess is probably due to malloc overhead.

location: 0x20002b70 - 0
location: 0x20002b78 - 1
location: 0x20002b88 - 2
..............
location: 0x20002de8 - 53
location: 0x20002df8 - 54
location: 0x20002e00 - 55
location: 0x20002e10 - 56
location: 0x20002e18 - 5

 

As you can see nothing is ever allocated between 0x20000a18 and 0x20002b70, about 2k of ram.  Using the debugger I took a look at what is being store there.  It's mostly 0, but I occasionally see part of string that I passed into printf.  Either printf and maybe other library also uses the heap that I don't know about, or this is just a residue of ram not being properly cleared.  I left the board unpowered for a few minutes, so it probably not the case.

 

This scares me because I am unaware of what's allocating memory in the heap and I am not sure if I can control it.  Can anybody shine some light into what's going on here?

 

Thanks for your assistant in advance.

 

Thanh Truong

Outcomes