{"id":15452,"date":"2023-08-19T14:03:29","date_gmt":"2023-08-19T08:33:29","guid":{"rendered":"https:\/\/fastbitlab.com\/?p=15452"},"modified":"2023-08-19T14:03:29","modified_gmt":"2023-08-19T08:33:29","slug":"stm32-analyzing-memory-consumption-and-testing-lvgl-on-stm32f429-board","status":"publish","type":"post","link":"https:\/\/fastbitlab.com\/blog\/stm32-analyzing-memory-consumption-and-testing-lvgl-on-stm32f429-board\/","title":{"rendered":"STM32-LTDC, LCD-TFT, LVGL(MCU3) Lecture 52| Analyzing memory consumption and testing LVGL on STM32F429 board"},"content":{"rendered":"
\n
\n
\n
<\/div>\n
\n

 <\/p>\n

Analyzing memory consumption and testing LVGL on STM32F429 board<\/b><\/span><\/h1>\n
\n
\n
\n
<\/div>\n

 <\/p>\n<\/div>\n<\/div>\n<\/div>\n

 <\/p>\n

\"Figure
Figure 1. Error message<\/figcaption><\/figure>\n

We have encountered a problem with our project. Essentially, the error indicates that our project’s ‘.bss’ section does not fit into the on-chip RAM, and we are not using any external RAM, such as SDRAM.<\/span><\/p>\n

Let’s investigate how our ‘.bss’ is overflowing. To do that, we will examine the memory map file of this project. Follow these steps: Right-click on the project \u2192 Go to properties \u2192 Navigate to the Resources section \u2192 In the location section, browse to the project directory.<\/span><\/p>\n

 <\/p>\n

\"Figure
Figure 2. Properties for project<\/figcaption><\/figure>\n

 <\/p>\n

Once in the project directory, go to the Debug section, and there you will find the project’s map file. <\/span><\/p>\n

\"Figure
Figure 3. Map file<\/figcaption><\/figure>\n

 <\/p>\n

Open that map file and browse through the document until you find the ‘.bss’ section (as depicted in Figure 4).<\/span><\/p>\n

As you can see here, the beginning of the bss is at address 0x00000000200000fc, and its size is 0x40000. This corresponds to 262,144 bytes.<\/span><\/p>\n

\"Analyzing
Figure 4. .bss section in map file<\/figcaption><\/figure>\n

 <\/p>\n

What is the size of our RAM? <\/span><\/p>\n

To do this, check the linker script in the project, where you’ll find that the RAM size is 192 kilobytes, which is around 262 kilobytes.<\/span><\/p>\n

\"Analyzing
Figure 5. Size of the RAM<\/figcaption><\/figure>\n

You can also see(Figure 4), what are all components that contribute to the growth of the .bss.<\/span><\/p>\n

For example, we have an I2cHandle, which is a structure. That contributes 0x54 this much bytes to the growth of the .bss. <\/span><\/p>\n

And the major contribution comes from .bss.my_fb, this frame buffer. As you can see, it adds around 150 kilobytes.<\/span><\/p>\n

 <\/p>\n

Apart from that, you can also observe that there are 2 display buffers named ‘display_buf1’ and ‘buf2’. These contributions come from the ‘tft.o’ file. Let’s analyze the ‘tft.o’ itself.<\/span><\/p>\n

\"Analyzing
Figure 6. Display buffers<\/figcaption><\/figure>\n

 <\/p>\n

To do this, I’ll go to the command prompt and navigate to my project directory. From there, I’ll access the Debug folder and further navigate into ‘hal_stm_lvgl’. Inside the ‘hal_stm_lvgl’ folder, I’ll locate the ‘tft’ file. And run the command ‘arm-none-eabi-size’ over the ‘tft.o’ file. <\/span><\/p>\n

As a result, you can see that the ‘.bss’ section of this file alone consumes 211600 kilobytes of RAM(Figure 7).<\/span><\/p>\n

\"Analyzing
Figure 7. Command prompt<\/figcaption><\/figure>\n

 <\/p>\n

After that, another significant memory consumption comes from the file ‘lv_mem.o,’ which results in a considerable memory usage. <\/span>
\n<\/span><\/p>\n

\"Analyzing
Figure 8. Lv_mem.o file<\/figcaption><\/figure>\n

 <\/p>\n

It amounts to ‘C000,’ approximately 49 kilobytes. This memory is consumed by the variable ‘work_mem_int.’<\/span><\/p>\n

\"Analyzing
Figure 9. Work_mem_int<\/figcaption><\/figure>\n

‘work_mem_int’ is a memory pool defined in the ‘lv_mem.c’ file. It essentially represents an array used by LVGL for dynamic memory allocation. The size of this memory pool is determined by the macro ‘LV_MEM_SIZE,’ which is defined in ‘lv_conf.h.’ Presently, it is set to 48 kilobytes, but it can be adjusted as needed. By modifying this macro, you can vary the size of the memory pool, and the ‘lv_mem_alloc()’ function allocates memory from this pool maintained by LVGL.<\/span><\/p>\n

 <\/p>\n

Now, let’s investigate why ‘tft.c’ is consuming such a significant amount of RAM space.<\/span>
\n<\/span>In ‘tft.c’, as shown in Figure 10, there is a frame buffer (<\/span>That’s a large array actually)<\/span>. Additionally, there are 2 display buffers, also known as Draw buffers.<\/span><\/p>\n

\"Analyzing
Figure 10. Draw buffers<\/figcaption><\/figure>\n

 <\/p>\n

Let’s understand the purpose of Draw buffers. <\/span><\/p>\n

\"Analyzing
Figure 11. Display driver file(tft.c)<\/figcaption><\/figure>\n

Unlike the frame buffer, the Draw buffers do not need to be screen-sized; they can be of any size, offering more flexibility. These buffers are used by LVGL to update graphic contents and render graphics efficiently.<\/span><\/p>\n

Here’s how the process works:<\/span><\/p>\n