Panic Handler invoked when heap_caps_aligned_calloc() unable to allocate memory to frame buffer (AEGHB-855)

[karunt]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Using Qualia ESP32-S3 board with RGB565 LCD (no touchscreen) screen, powered by ST7701 driver. Qualia ESP32-S3 board uses TCA9554 I/O expander to connect the LCD screen. The ESP32-S3 is also equipped with 8MB octal PSRAM. I'm trying to execute the RGB Avoid Tearing example on this board, but when the code tries to allocate frame buffers in function lcd_rgb_panel_alloc_frame_buffers (in esp_lcd_panel_rgb.c), it invokes a panel handler and reboots. It seems to fail at the following line:
rgb_panel->fbs[i] = heap_caps_aligned_calloc(psram_trans_align, 1, rgb_panel->fb_size, MALLOC_CAP_SPIRAM | MALLOC_CAP_8BIT);

Here's what my log looks like:
Log.docx

Here's what my sdkconfig (relevant sections only) and sdkconfig.default files look like:

sdkconfig.docx
sdkconfig_defaults.docx

Finally, here's what my partitions.csv file looks like:
partitions.csv

I have a feeling my issue has something to do with the configuration in my sdkconfig or sdkconfig_defaults files, especially with attempting to incorporate the 8MB of PSRAM, but I'm not entirely sure. Any help would be appreciated because I'm stalling at this point without a clue.

[Lzw655]

Hi @karunt, I checked your sdkconfig file and somePSRAM configurations differ from the defaults in the examples. Please refer to the file for confirmation. Specifically, the frequency should be set from 40M to 80M.

[karunt]

@Lzw655 Thanks. I've adjusted the sdkconfig files to resemble the example, but still the same issue persists. I seem to have 8388608 bytes of PSRAM when trying to flash the program onto the ESP32-S3. So why the issue with heap_caps_aligned_calloc()? Here's some additional info I get about the heap:

Heap summary for capabilities 0x00000404:
At 0x3c070000 len 8388608 free 8386092 allocated 204 min_free 8386092
largest_free_block 8257536 alloc_blocks 3 free_blocks 1 total_blocks 4
Totals:
free 8386092 allocated 204 min_free 8386092 largest_free_block 8257536

I'm at a loss and it's been 3 weeks now trying to resolve this. What else can I provide that will make it easier to navigate and resolve the problem?

[karunt]

Also, what's the purpose of psram_trans_align in heap_caps_aligned_calloc() and how is the correct value of this argument determined?

[Lzw655]

Did you modify any application code beyond the LCD and IO Expander in the example? Could you please use idf.py monitor to capture the logs, which will help identify the specific cause of the issue.

[karunt]

@Lzw655 For some reason, the settings from sdkconfig.defaults.esp32s3 weren't overwriting settings in sdkconfig. So I implemented the same settings in sdkconfig, rendering sdkconfig.defaults.esp32s3 redundant. And now it seems to work. At least I'm no longer seeing a panic handler being invoked. Thanks.

That said, what is the difference between CONFIG_EXAMPLE_LVGL_PORT_AVOID_TEAR_MODE_1, CONFIG_EXAMPLE_LVGL_PORT_AVOID_TEAR_MODE_2 and CONFIG_EXAMPLE_LVGL_PORT_AVOID_TEAR_MODE_3? I'm no sure I understand the difference from the lvgl library.

[Lzw655]

Mode1 and Mode2 are based on LVGL's full-refresh method, while Mode3 is based on LVGL's direct-mode method. The primary difference between these methods is that full-refresh redraws the entire screen even if only a single pixel changes, triggering a complete screen re-render. In contrast, direct-mode performs partial refreshes, rendering only the areas that have changed. Therefore, we usually recommend using Mode3.

I'm sorry I can't explain its implementation in detail, you'll need to look at the source code to understand it fully.

[karunt]

Thanks. That's helpful. What's also important for anyone else experiencing issues with a similar setup (ST7701S driven LCD, TCA9554 I/O expander and ESP32-S3 based module) is to update the initialization commands and data with what's been provided in the LCD driver documentation (in this case, ST7701). I haven't figured out how to interpret the init commands/data yet, but not updating them was preventing my screen from working for some reason.

[Lzw655]

You're right. The initialization commands and parameters of RGB timings are very important. So we also provide a detailed development guide (https://docs.espressif.com/projects/esp-iot-solution/en/latest/display/lcd/rgb_lcd.html) to introduce the process to drive a RGB LCD.