LVGL: Avoid Ram overflow error

How-to
22

mmmmm still hard faulting. I’ll keep looking into this, thanks for the help.

23

VGL_PORT.elf section .buffers' will not fit in region RAM_D1’
c:\st\stm32cubeide_1.5.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.win32_1.5.0.202011040924\tools\arm-none-eabi\bin\ld.exe: region `RAM_D1’ overflowed by 64992 bytes

hmmm still appears to be put in Ram_D1. No idea why.

24

The only thing I can think of is that the IDE is not actually using that linker script? Maybe it has another copy somewhere else which it uses?

25 
c:\st\stm32cubeide_1.5.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.win32_1.5.0.202011040924\tools\arm-none-eabi\bin\ld.exe: LVGL_PORT.elf section `.buffer' will not fit in region `BUFFER'
c:\st\stm32cubeide_1.5.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.win32_1.5.0.202011040924\tools\arm-none-eabi\bin\ld.exe: region `BUFFER' overflowed by 435712 bytes

So the good news is I was finally able to get it to actually go into the RAM section I wanted. I specifically overflowed it to test where it was being written.

Problem is now that LV_Task_Handler() is still hard faulting and my screen is remaining black. So progress?

26

So I isolated the problem. I can in fact save the array to the BUFFERs sections now and it can hold the entire array but anytime I attempt to reference it in put_px() it hard faults.


void put_px(uint16_t Xpos, uint16_t Ypos, uint32_t RGB_Code)
{

	image_data_framebufferDefault[Ypos * LayerWidth + Xpos] = RGB_Code;
}

This is all the function does.

27

Print the address again; I suspect your problem is that the SDRAM chip is not enabled for some reason.

28

image
image3520×1080 358 KB

29

For whatever reason the error seems to occur when the values are being written to the memory.

image
image3520×1080 1.44 MB

30

I could be wrong, but this would be the first I’ve heard of an STM32 chip having ram starting at a B address. Usually it starts at 6xxx or Cxxx. I think you might still have the wrong address.

31

I think the origin is expected to be 0xC0000000, not 0xC000000, and the length shall be 640kb or more… And if I’m not wrong, for the STM32H7 MPU region settings shall be properly configured. Unfortunately I had no experience with them.

32

so I have updated the address and memory size. I seem to be able to render a white image, which is the default frame buffer im loading in, on the initial startup but LVGL doesn’t seem to be updating the frame buffer at all.

It loads in the white image to the frame buffer with the correct dimensions then just stops. The same code works assuming I do not store the fb in .buffers.

Do I need to tell LVGL where exactly in the memory this is being stored? As I thought simply referencing it like this would work.

void put_px(uint16_t Xpos, uint16_t Ypos, uint32_t RGB_Code)
{

	image_data_framebufferDefault[Ypos * LayerWidth + Xpos] = RGB_Code;
	pLayerCfg.FBStartAdress = (uint32_t)&image_data_framebufferDefault;
	//HAL_LTDC_ConfigLayer(&hltdc, &pLayerCfg, 0);


}