How to manage the Flash and the SRAM? (and how is it already managed?)

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I am currently programming an embedded application on the Atmel SAML21J18A Board, which has the following characteristics:

 

- 256KB Flash
- 40KB RAM

 

When I program the board, I have the following message :

    Program Memory Usage     66428 bytes    24,6 % Full
    Data Memory Usage     29112 bytes    71,1 % Full

 

Tell me if I am wrong, but it seems that even before my application starts, I
already have 71% or my SRAM that is consumed, which seems huge.

So, I have several questions for you guys :

- Do I really have 71% of my RAM that is taken at the very beginning of the
  application ? If yes, do you think that having only 10KB left is sufficient
for my application ? (I personnaly don't think so, even tho it has no
graphical stuff, 10KB seems really low)

- I have ony 24% of my flash that is used, how could I use more of it ? Does
  it change something if I use the "malloc" function ? Will it store it in the
flash instead of the RAM ? Is the only difference between Flash and SRAM the
time taken to access the data ?

- How does the Atmel memory allocation works ? If I declare a variable but the
  SRAM is already at 100%, will it allocate it in the flash ? What decides
what is in the flash and what is in the SRAM Anyway ?

- I am using FreeRTOS and I saw that changing the value of the
  configTOTAL_HEAP_SIZE can change the "Data Memory Usage" percentage, what
does it mean ?

- I found the file "saml21j18a_flash.ld" which decides the sizes of the rom,
  rom, ram, lpram and picoram, and also the "STACK_SIZE". If I want a higher
stack size, should I change the value in this file or is it dangerous ? Why
doesn't it already use the maximum size available ?

Thank you guys for taking the time to answer to those questions, and I would
be glad to take any advice about memory usage and optimisation, thanks.

 

Last Edited: Mon. Apr 11, 2016 - 04:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm no moderator, but your post has a lot of questions pertaining only to an ARM chip and a RTOS that really doesn't fit onto an AVR, posted on a board dedicated to the AVR series of processors. Also, you didn't post how much code you are compiling or what compiler you are using. I will offer the suggestion that if you are using malloc() on a microprocessor you are just asking for memory management trouble.

 

[moderator - I've moved the thread from AVR though, to be honest I didn't really know which ARm forum was appropriate - hope I guessed right!]

Last Edited: Mon. Apr 11, 2016 - 04:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Apart from the chip, there is nothing specifically Atmel in these questions.
First up, flash data doesn't change unless you reflash it. So you might put message strings in flash. You use the C const keyword to allocate a variable in flash. If you run out of ram, too bad, no magic happens apart from your program crashing.
You've chosen freeRtos. That needs ram and stack for each task. You determine how much ram is allocated for this. More tasks, more ram. Stack lives in ram. Allocate more stack, chew up more ram. Same with heap. So, if you're not careful with the allocation you can easily find yourself in the situation you are now. How much ram should you allocate? That's a good question as it depends on your program. I think you need to read up on how C allocates memory - ie local vars vs globals and statics. Then read up on how freeRtos works. Then you should be able to make an educated guess. The rest is experience.

Last Edited: Mon. Apr 11, 2016 - 11:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

- Do I really have 71% of my RAM that is taken at the very beginning of the application ?

Yes?  That includes all global variables, and all "static" local variables.  For an RTOS, it might also include the stacks for each defined process, even though the stack is "empty."  It might also include the initial stack (it wouldn't on AVR, but I'm not sure on ARM.)

 

If yes, do you think that having only 10KB left is sufficient for my application ?

Impossible to say without seeing your program.  In theory, the only thing that uses additional RAM is malloc(), and MAYBE context and local variables on a stack that doesn't otherwise show up in the memory already used.

 

- I have ony 24% of my flash that is used, how could I use more of it ?

Write more code.  Declare variables that are constant "const."   Flash cannot be changed at runtime, so it only holds code and constants.

 

- How does the Atmel memory allocation works ? If I declare a variable but the  SRAM is already at 100%, will it allocate it in the flash ?

Define "declare a variable" more clearly.  All of your global and static variables are already using the memory as reported; it's not like a global variable in some library doesn't actually get allocated until you reference that library.  malloc() and similar will explicitly allocate memory, if you use them.   local variables and stack frames will allocate memory on the current stack, which may or may not be already allocated by other code.

 

- I am using FreeRTOS and I saw that changing the value of the configTOTAL_HEAP_SIZE can change the "Data Memory Usage" percentage, what does it mean ?

The "heap" is normally the memory used for malloc().  FreeRTOS may specifically reserve an area of memory for its specific version of malloc(), if it has one.

 

- I found the file "saml21j18a_flash.ld" which decides the sizes of the rom,  rom, ram, lpram and picoram, and also the "STACK_SIZE".

Some of those variables describe physical memory areas on the chip, and aren't user-changeable.  STACK_SIZE may refer to the initial stack size, which may be irrelevant when using an RTOS.

 

If I want a higher stack size, should I change the value in this file or is it dangerous ? Why doesn't it already use the maximum size available ?

 Usually, memory added to the stack (local variables) is lost from the heap (malloc).  A good implementation of malloc() would not allow memory reserved for the stack to be allocated for other purposes.

 

RTOSes can complicate things by having a stack for each process, sometimes allocated from the heap when the process is created and sometime allocated at compile time.  If you're using freeRTOS, probably most of your questions are better thought of as "FreeRTOS memory allocation questions", rather  than "Atmel memory allocation."  See http://www.freertos.org/a00111.html

 

You can use the linker map, or the output of the "nm" command to see what data structures are actually using the memory reported by the 'size' command.  (Obviously it won't say anything about memory allocated at runtime.)  Here's some sample output from an Arduino Zero sketch:

 /Applications/arduino/Arduino-1.6.5.app/Contents/Java/portable/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-nm -CnS --size-sort *.elf | grep -i ' [bd] '
20000617 00000001 B USBDevice
20000190 00000001 b isEndpointHalt
20000615 00000001 b isRemoteWakeUpEnabled
20000616 00000001 B _dry_run
20000614 00000001 B _pack_message
20000292 00000002 B _pack_size
20000000 00000004 D SystemCoreClock
20000850 00000004 b guard variable for PluggableUSB()::obj
20000004 00000004 d ticks
2000018c 00000004 b _ulTickCount
20000720 00000004 B _usbConfiguration
20000618 00000004 B _usbSetInterface
20000174 00000004 B sercom0
20000178 00000004 B sercom1
2000017c 00000004 B sercom2
20000170 00000004 B sercom3
20000180 00000004 B sercom4
20000184 00000004 B sercom5
20000188 00000004 b usb_isr
20000074 00000008 d _usbLineInfo
20000848 00000008 b PluggableUSB()::obj
20000830 00000018 B SerialUSB
20000008 00000028 D EndPoints
20000030 00000042 d _cdcInterface
200000b0 00000060 B Serial
20000110 00000060 B Serial1
20000191 00000100 B _pack_buffer
2000061c 00000104 B usbd
20000724 0000010c B cdc_rx_buffer
20000294 000001c0 b udd_ep_in_cache_buffer
20000454 000001c0 b udd_ep_out_cache_buffer

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for those answers, it helps me a lot.