STM32G431CBU: section `.bss' will not fit in region `RAM'

[ValterMatos]

Good morning.
Could anyone tell me about this error and how to resolve it.
C:/ST/STM32CubeIDE_1.19.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.13.3 .rel1.win32_1.0.0.202411081344/tools/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld.exe: Oscillo_STM32G431CBU.elf section `.bss' will not fit in region `RAM'
C:/ST/STM32CubeIDE_1.19.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.13.3 .rel1.win32_1.0.0.202411081344/tools/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld.exe: region `RAM' overflowed by 54928 bytes
I'm using IDE 1.19 to compile the code for a G431CBU
Grateful

Valter Matos

[ValterMatos]

It seems I undersized the g431C for this code with this display.

A smaller touchscreen display wouldn't be suitable.

Understood.

I'll look into a solution.

Thank you.

[ValterMatos]

I'm not doing well.
I managed to get some G431 boards donated for the students, but they have too little memory for the chosen project.

Thank you.

Good night.
Valter Matos

[Andrew Neil]

I think TouchGFX has some "clever tricks" for working on low-RAM chips - by not allocating a full frame buffer...?

But, at the end of the day, graphics is memory intensive!

[Ozone]

It seems I missed a bit of the conversation ...

> It seems I undersized the g431C for this code with this display.
> A smaller touchscreen display wouldn't be suitable.

GUI operations are relatively memory intensive, for sure. And they require a relatively fast connection between controller and display.

You could either scale back your project (including display size), or go for an MCU with more resources.
I think trying to cram an oversized GUI model into such a resource limited hardware overburdens most students.
That would be a task for an experienced engineer.

[mƎALLEm]

---

@Andrew Neil wrote:

So you have:

#define ILI9488_TFTWIDTH  	320
#define ILI9488_TFTHEIGHT 	480

and

/**
 * @brief Buffer storing 4-bit color values for each LCD pixel.
 * Each byte represents color information for two adjacent pixels, utilizing 4 bits per pixel
 */
static uint8_t image_buffer[ ILI9488_TFTWIDTH*ILI9488_TFTHEIGHT/2 ] = {0};

which becomes

static uint8_t image_buffer[ 320*480/2 ] = {0};

320*480/2 = 76800 bytes !

ie, 75K bytes

Which is exactly what @KnarfB said earlier - from the map file.

---

And that's what I also mentioned from the beginning: large table declared in the application ;)

[Andrew Neil]

---

@Ozone wrote:

That would be a task for an experienced engineer.

---

Indeed it is!

@ValterMatos  Seems we're still talking about this "oscilloscope" project - yes?

As noted there, I really can't see how this is a valuable learning experience in the situation described.

[Ozone]

> @ValterMatos  Seems we're still talking about this "oscilloscope" project - yes?

In this context, the OP's statement that a smaller display wouldn't cut it seems understandable.
But the remainder of this oscilloscope project, i.e. the "non-GUI" runtime engine, is equally challenging for beginners.

By sheer coincidence, I'm on a somewhat similiar project at the moment.
But the STM32 (in my case a F303K8) only does the real-time data collection, and postprocessing, display and storage happens on a Linux host (Raspberry Pi ZII).

[Andrew Neil]

---

@Ozone wrote:

the remainder of this oscilloscope project, i.e. the "non-GUI" runtime engine, is equally challenging for beginners.

---

Absolutely.

And it seems that the target audience is electronics focussed - not software.

It seems to me that any electronics learning is going to be lost with all the software complexities.

[LCE]

@Andrew Neil wrote:

> And it seems that the target audience is electronics focussed - not software.

> It seems to me that any electronics learning is going to be lost with all the software complexities.

100% agreed !

We find many people here who come from the software side or are beginners in general, they often have no idea about basic electronics, using an oscilloscope, MCUs in general and that these are mostly not machines with GBs of RAM and flash and GHz clocks.

Throwing a graphics project at them... too much in general - and not enough electronics.

Maybe they should start getting UART, ADC, DAC to work (without HAL), then checking IOs on the scope, playing with filters on the digital and analog side, etc...

[waclawek.jan]

The ILI9488 controller contains videoRAM, so you don't need to allocate it in the mcu.

Of course, all the graphics routines have to be written with this in mind.

JW