SRAM .data size issue? « LeafLabs Garden

LeafLabs Garden » Support » Maple IDE Support

SRAM .data size issue?

(8 posts) (4 voices)

Started 3 years ago by beachbum
Latest reply from gbulmer

beachbum
Member

Hi, love the Maple! Thanks, LeafLabs, for doing this!

I'm doing a LED lights project, and running into a hard problem with the SRAM usage though on my Maple R5. I'm using the IDE (v0.0.12) on Winblows XP, compiling for a Maple R3+ uploading the program to flash. My program bombs and the LED sometimes throbs when .data, as reported on IDE compilation, goes over the Maple's 20KB (20,480 bytes) of SRAM.

Prob is, when the IDE compilation reports a .data size right at 20,480 bytes, i then run arm-none-eabi-size on my lights12.cpp.elf file, which reports text=17564 data=2912 bss=7400 dec=27876 (the bss is large because of two big arrays). It seems that the .data size is reported, and thus the size that tried to be loaded into the SRAM, consists of (text=17564 + data=2912) to get to 20,476. Shouldn't the .data size that gets loaded into SRAM instead be (data + bss + space for the stack) since text only gets loaded into ROM/flash?

As a comparison, i compiled "blink", and the IDE compilation reports a .data size of 12840. Then running 'size' on blink.cpp.elf reports text=11215 data=1624 bss=416 dec=13255). Note that blink's text + data = 12839, resulting in the reported .data of 12840.

Could a bug be in the compilation process resulting in this? I checked the flash.ld config file that gets called, and it does indeed try to load "REGION_TEXT" to rom, and "REGION_DATA" to ram.

Is there anything i could do to get around this? I would strongly prefer not to buy another computer to load Linux and setup the UNIX tool chain to then tweak the Makefile. My preferences are if a config file somewhere could be changed, or download a .exe or .dll that makes this correction, or barring that, unsolder the normal RBT chip and try to solder in a RET6 chip.

As always, i could have been doing something stupid, but i don't see it if i am. I have run my program numerous times, and the problem occurs right when the reported .data goes over 20,480 bytes, despite numerous changes i made to functions in the program, so it's not related to any specific 'C' code.

Any suggestions or ideas?

Thanks in advance!!!!!

Posted 3 years ago #
beachbum
Member

The solution perhaps may be in a linker script, which may be somewhere in the downloaded arm tools tree, and be editable. Does anyone know which .ld or armelf.x? linker script is called for the Maple R3+ going to flash? Thanks in advance.

Posted 3 years ago #
crenn
Moderator

Do you have a large non-constant data array by chance? Could you post your code in pastebin for us to see?

Posted 3 years ago #
beachbum
Member

Thanks, crenn. The data arrays were larger in previous version of my code prior to reducing them in half. I'll spend the evening trying the code in another 10 different ways to isolate further. There is a chance that, by coincidence, the IDE compile reported .data of (text+data) went over the 20KB SRAM limit at the exact same time that the (data+bss+stack+alignments+padding) went over the 20KB limit.

It took me a while to figure out to run arm-none-eabi-size on the <myprogram>.cpp.elf file to get the necessary info. Stack/memory overflows are fun! ;-)

Posted 3 years ago #
gbulmer
Moderator

beachbum - The bootloader consumes SRAM.
The first thread I found is this from September 2010: http://forums.leaflabs.com/topic.php?id=157#post-996

which says 3KiB are reserved. I do not believe the Maple bootloader has been updated to use less SRAM since then.
So the SRAM limit is 17KiB

Are the large-ish data arrays constant or not? If they are constant, they can be stored in Flash, and won't consume any RAM.
This post gives an example: http://forums.leaflabs.com/topic.php?id=1009#post-6210

(Full disclosure: I am not a member of LeafLabs staff.)

Posted 3 years ago #
beachbum
Member

Yep, yinz are right. My bad. Sorry. Whoops. Thanks for the help.

After doing 20+ compiles last night, i verified that it was just a coincidence that my actual SRAM usage went over the 20KB (17KB) limit at the same compile as when the IDE reported the funnily calculated .data of (text+data), went over the 20KB limit.

For info to others, for when uploading to flash, recommend calculating your SRAM usage by using arm-none-eabi-size on your <mysketch>.cpp.elf file, and making sure your (data+bss) is less than approximately the 15KB to 16KB range on a 20KB SRAM device. There's a bit of an area where one gets hard to debug program bombs before the compiler/linker catches that one is using too much SRAM and gives the red failure message. One needs to keep in mind that various overheads included in your sketch, as reported by "blink", use 2KB+ of SRAM, and then there's the 3KB reserved for the bootloader (thanks, gbulmer!). The stuff that needs to be in SRAM include (data + bss + stack + alignments + maybe padding + space reserved for bootloader) if uploading to flash is selected. And, one needs to also add in the text section if uploading to SRAM is selected.

That was a fun 4 days trying to solve this ;-)

Again, love the Maple! Thanks for doing this project!

Posted 3 years ago #
go61t
Member

Hi there,

I always see a size of 13KB in total for the compiled code when using SRAM. even if the code is almost without any statements. why is the code that big? for projects using sd card or realtime the code is exceeding the availale space by far!

what are the possibilities to extend the sram without to use flash instead. How often flash could be rewritten!

Thanks, Sebastian - cu

Posted 3 years ago #
gbulmer
Moderator

go61t - The number of times Flash can be rewritten is explained here:
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00161566.pdf
in the section titled "5.3.9 Memory characteristics"

An STM32F103RBT6 doesn't not have an interface to external memory, so its RAM can't be extended.

Maple Native described at http://leaflabs.com/devices/ has 64KB SRAM (on-chip), 1MB SRAM (external)

Posted 3 years ago #

RSS feed for this topic

Reply

You must log in to post.