Does new project use all the available RAM?

[JBond.1]

I have created new project with STM32CubeMX for my STM32F091RC. I have noticed that when allocating memory it ends very fast. Do I need to change any settings to use all of the available 32Kb of memory?

In "startup_stm32f091xc.s" I find these values:

Stack_Size      EQU    0x400

Heap_Size     EQU    0x200

Should they be much bigger? Why default project does not use max available memory? What maximum values I can use?

[waclawek.jan]

Stack and heap holds only part of the variables - global and static variables are located in the remaining space.

JW

[Pavel A.]

Yep, 32K is not much. Be frugal, watch your memory map.

-- pa

[Tesla DeLorean]

>>Should they be much bigger? 

Do you use malloc(), how much memory do you actually need to dynamically allocate. A lot of embedded systems use very little or no dynamically allocated memory.

Again with the stack, what do you actually use? Have you looked at the call-tree and expectations output by Keil.

Memory in general, look at the .MAP file, get an idea about what your needs/requirements actually are.

[JBond.1]

32Kb = 0x7FFF, stack and heap gets only 0x400, 0x200 so ALL the rest 0x79FF is for global and static variables?

Does it really use "ALL" the remaining space?

[JBond.1]

Yes, I tried using malloc() for linked list and the app crashed really fast I added like ~100 integers to the list, and there were no more space. I would like to read files from SD card, so I guess I would need more than that.

Also when I tried using default FatFS library v0.11 from STM32CubeMX I had hard fault error. it seems that stack is also too small. I found another FatFS library: https://github.com/SL-RU/stm32_file_viewer/ which seems to work without changing stack size. So I guess it use some kind of optimization or static variables. Which FatFS library would you recommend?

But still I need more memory for reading files and so on. I guess I can use static variables. .MAP file should say if I have enough space for static variables?

I guess the key here is to use STATIC variables as they get all the 0x79FF space?

[Tesla DeLorean]

The stack and heap should be set based on your usage expectations.

The Linker assigns the open space to your other variables as needed. If you run out of space it will warn you.

Hard Faults can occur for several reasons, one needs to inspect the faulting code to understand the reason.​

[Ozone]

> I guess the key here is to use STATIC variables as they get all the 0x79FF space?

Or so.

Avoid malloc() or similar functions if possible, use a static memory layout (i.e. fixed at compile time).

malloc is used sometimes to port PC/Unix software. However, each byte to be allocated must "carved out" from the small MCU RAM.

malloc's take the memory from HEAP.

> Also when I tried using default FatFS library v0.11 from STM32CubeMX I had hard fault error. it seems that stack is also too small. I found another FatFS library: ...

Stacksize is a (usually) project property, and easy to change.

The hardfault can have other reasons - like accessing stack variables (auto variables) that do not longer exist.

[JBond.1]

>Stacksize is a (usually) project property, and easy to change.

>The hardfault can have other reasons - like accessing stack variables (auto variables) that do not longer exist.

>Hard Faults can occur for several reasons, one needs to inspect the faulting code to understand the reason.​

Well when I changed stack from 0x400 to 0x600 the program ran without hard faults any more. I tried to increase stack after reading this post, which suggest that stack is the issue:

https://community.st.com/s/question/0D50X00009Xkent/stm32f10xfatfssdio-dma-hardfault

And indeed increasing stack no more hard faults. But why it was not increased automatically after creating project if I selected FatFS to add to my project? Also should I increase it manually?

[Ozone]

> Also should I increase it manually?

Always.

Stack usage is very difficult to estimate beforehand. Libs/packages libe FatFS do not come with a stack usage label.

Code complexity and other things (e.g FPU usage) have an effect as well.