Maple r5 flash memory overflow with only 50KB load

LeafLabs Garden » Support » Maple Hardware Support

Maple r5 flash memory overflow with only 50KB load

(6 posts) (2 voices)

Started 4 years ago by polpla
Latest reply from polpla

polpla
Member

Hi!

I am using IDE version 0.11 on OSX with a Maple r5 and I am having memory problems compiling a code for addressing a lcd display. I was trying to buffer the images before displaying using a byte array. The screen is 128x128 and it stores color in 3 bytes per pixel. When I try to compile my code (with device r3+ flash selected) I get the following error:

-------------------------
elf section .bss' will not fit in regionram'
/Applications/MapleIDE.app/Contents/Resources/Java/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/bin/ld: region `ram' overflowed by 33784 bytes
-------------------------

To make sure that it was independent of my code I created an simple sketch where I only declare the array and use it once. The code looks like this:

-------------------------
byte buffer[128][128][3];

void setup(){
buffer[0][0][0] = 0x32;
}

void loop(){}
-------------------------

I got the same error:

-------------------------
elf section .bss' will not fit in regionram'
/Applications/MapleIDE.app/Contents/Resources/Java/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/bin/ld: region `ram' overflowed by 33768 bytes

collect2: ld returned 1 exit status
-------------------------

If my math is right:
128x128x3 = 48.952bytes ~ 49Kbytes

The documentation says that the Maple r5 should support out of 120KB (for what I have read in other posts 108KB because of the bootloader). However, it seems that it is not able to fit 49KB.

One of the things that does not look right to me is that the error talks about 'ram' when I have the "Maple Rev 3+ Flash" option selected in my tools menu. If there is overflow it should be of flash memory. Of course, 49KB don't fit on the ram (which is 20KB minus bootloader overhead) but they should fit in 108KB.

Am I doing something wrong? Can someone help with this?

Thanks in advance!!

Posted 4 years ago #
robodude666
Member
The Maple has 120kB of FLASH memory, and 20kB of RAM.

The application you are writing is stored in FLASH. Your data, such as variables, arrays, etc. is stored in RAM. The array you've created is statically allocated and stored in RAM memory. Because it is 49kB, and larger than the 20kB RAM you have available it cannot be allocated and therefore you receive an overflow in the ram region.

The two options you see in the MapleIDE, Flash and Ram modes, control where the program gets uploaded to. If you select Flash, it will be written to the 120kB FLASH memory and will be present on bootup (it won't be lost when powered down). If you select Ram, it will be written to the 20kB RAM memory and will be lost upon disconnecting power however it will run faster.

If you need to store a large array of read-only data, you can mark an array as __FLASH__ and it will be written to FLASH memory. This is similar to the Arduino's PROGMEM. For example:
```
static const uint8 mybuffer[10] __FLASH__ = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
```
Will create an 8-byte array in FLASH memory that is READ ONLY. There is a way to write to FLASH memory during run time, but it's strongly advised against.

If you are trying to buffer an image for an LCD, you will have to use external SRAM and manually interface with it. This can be done via a Parallel interface for best performance, or an SPI RAM/FLASH module.

Alternatively, the yet-to-be-released Maple Native features a higher-end STM32 MCU that has an onboard FSMC with a MB or so of external SRAM.

-robodude666
Posted 4 years ago #
polpla
Member

Thanks robodude666!

That clarifies things a lot. I guess I'll have to create my own board to interface with the screen and make sure I pick up a micro that has enough SRAM to store my buffer.

Posted 4 years ago #
polpla
Member

In the meantime, although it is highly discouraged, could you explain how to write variables to flash memory?

Thanks again!

Posted 4 years ago #
robodude666
Member

The best I can do is direct you to two pages:

ST's PM0075 Programming Manual - STM32F10xxx Flash memory controllers and a thread on the forums: Storing data in Maple's flash memory; specifically, the third post by poslathian. Like poslathian said, it's discouraged so use at your own risk.

Which LCD are you using? Most LCDs have their own GRAM, with the ability to write directly to the GRAM. If your program is written correctly, you won't have to buffer a single thing.

I've been playing around with a number of LCDs, and while I originally started with a goal of buffering the LCD locally on the MCU I realized it would become to problematic of a solution and I found other ways of doing it.

-robodude666

Posted 4 years ago #
polpla
Member

Yes, I have been reading more on the topic of writing on Flash memory and it is discouraged because it will eventually destroy it. Apparently flash memory has a life of around 100K writes and it becomes unusable after that. That is, if I was buffering images there for 30 minutes I will need to replace the micro. We don't want that to happen ;) so, I understand why it is discouraged (and I subscribe).

Regarding your question, I am not using an LCD but an OLED display. The model that I am using is the NEWTECH NL128128C that I bought from Sparkfun. This display does not have extra GRAM, it only has 128x128x18bits which is the memory necessary for the current frame.

However, I did further research and there are three approaches to work around this memory problem with displays:

1) The Maple RET6 offers 64K of ram. That should be enough to store at least one buffer in my case (if you work really hard on optimization you might be able to even squeeze two).

2) Work with a color pallet with a subset of the colors. The specific screen that I am using can do color up to 18bit color (6bits per color, total of 262K colors). If you reduce the amount of bits to encode color the required size for the buffer will consequently be smaller so you might be able to fit the buffer in the 20K ram of the regular Maple. For example, if you encode color in 8bits (3red,3green,2blue) you will only need 128x128 (16KB). You can also create a look up table if you want to configure a pallet of colors (make sure to hard code it so that it gets stored into flash).

3) Finally there is the bufferless approach. This technique requires a higher programming expertise and consist on keeping track of all the different elements or "sprites" on your image and calculate each frame on the fly. You want to give each sprite coordinates, size and shape as well as depth (to solve collisions).

Since I am not willing to sacrifice color I am going to try both 1 and 3 (maybe even a combination of both) and see how it goes. I'll post here as soon as I make some progress

Posted 4 years ago #

RSS feed for this topic

Reply

You must log in to post.