cancel
Showing results for 
Search instead for 
Did you mean: 

How to persuade linker not to copy const data arrays from flash into RAM at startup

herbert
Associate III

Hello Community,

I have several really large const arrays (with graphics data for LCD displays) which need not to be copied into RAM at startup, as this overflows my available RAM (on STM32F411 Discovery board). As there is no way to configure such behavior in STM32 Cube IDE I have tried to modify the linker scripts but GCC linker keeps ignoring my modifications.🙄

Does anybody have experienced the same problems or have some ideas how to convince the linker not to copy that sort of data into RAM? Data access speed is no issue as the speed bottleneck is in any case the display (connected via SPI).

Thank you for any ideas or suggestions
Herbert

1 ACCEPTED SOLUTION

Accepted Solutions

 

I suspect there's another issue here, perhaps a different array.

Reduce the size so it works and show the RAM .data section to show that it actually makes it in there. The screenshot doesn't show anything, just that some data is copied over, which it should be.

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

10 REPLIES 10
AScha.3
Chief II

In STM32 target hardware(that is in our embedded hardware), all global const variables live in FLASH memory.

By default, all global const variables will be stored in read-only memory or the FLASH.

<  from: https://fastbitlab.com/microcontroller-embedded-c-programming-lecture-130-placements-of-const-variables-in-memory/

 

so, what did you write?

ie from prog on stm32f103 : graphics font for tft 

AScha3_0-1697456366695.png

and in mem:

AScha3_1-1697456422010.png

 

If you feel a post has answered your question, please click "Accept as Solution".

Unfortunately, this is not fully correct. Space is also reserved in RAM, and the startup code (startup_stm32f407xx.s) initially copies all data from Flash int RAM. See the relevant part from my startup file (auto-generated by Cube IDE) in the attachment.

These are my Error messages:

/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.macos64_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: CreepyEyes_Production.elf section `.bss' will not fit in region `RAM'

/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.macos64_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: region `RAM' overflowed by 67824 bytes

collect2: error: ld returned 1 exit status

make: *** [makefile:64: CreepyEyes_Production.elf] Error 1

ok, so for F411 board:

AScha3_0-1697457439612.png

and (with unmodified settings)

AScha3_1-1697457496754.png

const var -> in flash. only.

(here a flac+ mp3 decoder running, tables never would fit in his small ram)

++ found F407 prog now:

AScha3_2-1697457695554.png

gives

AScha3_3-1697457734556.png

 

If you feel a post has answered your question, please click "Accept as Solution".

I have done that already, but the error messages remain:

Bildschirmfoto 2023-10-16 um 14.02.25.png

 Frankly, I have completely run out of ideas by now.

--- me too. 🙂

just ... my compiler settings are (most times) -O2 . (but this should not change basic C behaviour.)

try..

If you feel a post has answered your question, please click "Accept as Solution".

last idea:  try to give the place...  (not sure, that i write it correct)

__attribute__((section(".rodata"))) const uint8_t MY_ARRAY[] = { 1, 2, 3, 4 };

makes

AScha3_0-1697462719118.png

 

If you feel a post has answered your question, please click "Accept as Solution".
Bob S
Principal

Look in your map file (output from the linker).  If you don't have a map file, go to your project properties in the IDE, the under "C/C++ Build" then "Settings" click on the "General" entry under "MCU G++ Linker".  Check the "Generate map file" line.  If you want, post your map file here so we can take a look.

I agree with @AScha.3 that your "sclera" storage should be in flash, not RAM.  I do that all. the. time.

 

I suspect there's another issue here, perhaps a different array.

Reduce the size so it works and show the RAM .data section to show that it actually makes it in there. The screenshot doesn't show anything, just that some data is copied over, which it should be.

If you feel a post has answered your question, please click "Accept as Solution".

Here is my map file. No secret in there. I have just renamed it from .map to .log so that st will allow me to post it here.