Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESP32S3: LCD: DMA buffer in PSRAM doesn't work properly (IDFGH-6426) #8085

Closed
2 of 3 tasks
JadedTuna opened this issue Dec 14, 2021 · 3 comments
Closed
2 of 3 tasks
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally

Comments

@JadedTuna
Copy link

Environment

  • Development Kit: ESP32-S3-DEVKITC-1-N8R2
  • Kit version (for WroverKit/PicoKit/DevKitC): -
  • Module or chip used: ESP32-S3-WROOM-1-N8R2
  • IDF version (run git describe --tags to find it): v5.0-dev-676-g5c33570524
  • Build System: idf.py
  • Compiler version (run xtensa-esp32-elf-gcc --version to find it): xtensa-esp32-elf-gcc (crosstool-NG esp-2021r2) 8.4.0
  • Operating System: Linux
  • (Windows only) environment type: -
  • Using an IDE?: No
  • Power Supply: USB

Problem Description

Rendering to a display using esp_lcd_panel_io_tx_color does not work properly if the buffer is in PSRAM. Buffer is allocated using heap_caps_aligned_alloc(16, ...). Between each render call buffer is memset with a value, and the cache flushed using Cache_WriteBack_Addr. The effect is that every second render call works, but there is some data left over from the previous memset.

This works just fine if the buffer is in internal RAM.

Expected Behavior

For it to work the same way as with a buffer in internal RAM.

Actual Behavior

Effectively, this is what happens:

  1. allocate buffer in PSRAM
  2. memset with red color, flush cache
  3. draw (nothing is drawn)
  4. memset with blue color, flush cache
  5. draw (blue is drawn, but the first ~64 pixels are red)

Steps to reproduce

I have a minimal example which showcases the issue by running the same blitting code with a buffer in internal RAM and a buffer in PSRAM.
The display I use uses a R61529 controller, which IDF does not have a driver for. I wrote a basic driver that has enough functionality to init the display and blit a buffer. While there might be an issue in this driver, I feel that's unlikely, since the code is pretty much a copy of the code from IDF, and everything works fine if the buffer is in internal RAM.

The pin connections are defined in the code.
Here is an image which showcases some parts of the previous data in the buffer remaining (note that when the buffer is filled with black, which is the previous draw call, it is not rendered, as described in Actual Behavior).
20211214_210818

Code to reproduce this issue

Minimal example

Debug Logs

--- idf_monitor on /dev/ttyACM0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x42019d72
0x42019d72: esp_pm_impl_waiti at <redacted>/esp-idf/components/esp_pm/pm_impl.c:847

SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd0108,len:0x171c
load:0x403b6000,len:0x8c8
load:0x403ba000,len:0x2ed8
entry 0x403b61c0
I (24) boot: ESP-IDF v5.0-dev-676-g5c33570524 2nd stage bootloader
I (25) boot: compile time 19:16:40
I (25) boot: chip revision: 0
I (28) boot.esp32s3: Boot SPI Speed : 80MHz
I (33) boot.esp32s3: SPI Mode       : DIO
I (37) boot.esp32s3: SPI Flash Size : 2MB
I (42) boot: Enabling RNG early entropy source...
W (47) bootloader_random: RNG for ESP32-S3 not currently supported
I (54) boot: Partition Table:
I (58) boot: ## Label            Usage          Type ST Offset   Length
I (65) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (73) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (80) boot:  2 factory          factory app      00 00 00010000 00100000
I (88) boot: End of partition table
I (92) esp_image: segment 0: paddr=00010020 vaddr=3c020020 size=09610h ( 38416) map
I (107) esp_image: segment 1: paddr=00019638 vaddr=3fc91630 size=0289ch ( 10396) load
I (111) esp_image: segment 2: paddr=0001bedc vaddr=40374000 size=0413ch ( 16700) load
I (121) esp_image: segment 3: paddr=00020020 vaddr=42000020 size=1a934h (108852) map
I (145) esp_image: segment 4: paddr=0003a95c vaddr=4037813c size=094f0h ( 38128) load
I (154) esp_image: segment 5: paddr=00043e54 vaddr=50000000 size=00010h (    16) load
I (160) boot: Loaded app from partition at offset 0x10000
I (160) boot: Disabling RNG early entropy source...
W (163) bootloader_random: RNG for ESP32-S3 not currently supported
I (181) spiram: Found 16MBit SPI RAM device
I (181) spiram: SPI RAM mode: sram 40m
I (181) spiram: PSRAM initialized, cache is in normal (1-core) mode.
I (186) cpu_start: Pro cpu up.
I (190) cpu_start: Starting app cpu, entry point is 0x40375198
0x40375198: call_start_cpu1 at <redacted>/esp-idf/components/esp_system/port/cpu_start.c:164

I (0) cpu_start: App cpu up.
I (615) spiram: SPI SRAM memory test OK
I (623) cpu_start: Pro cpu start user code
I (623) cpu_start: cpu freq: 160000000 Hz
I (623) cpu_start: Application information:
I (626) cpu_start: Project name:     app-template
I (632) cpu_start: App version:      13396e4-dirty
I (637) cpu_start: Compile time:     Dec 14 2021 19:16:32
I (643) cpu_start: ELF file SHA256:  03b3a019543dd5da...
I (649) cpu_start: ESP-IDF:          v5.0-dev-676-g5c33570524
I (656) heap_init: Initializing. RAM available for dynamic allocation:
I (663) heap_init: At 3FC948C8 len 0004B738 (301 KiB): D/IRAM
I (669) heap_init: At 3FCE0000 len 0000EE34 (59 KiB): STACK/DRAM
I (676) heap_init: At 3FCF0000 len 00008000 (32 KiB): DRAM
I (682) heap_init: At 600FE000 len 00002000 (8 KiB): RTCRAM
I (688) spiram: Adding pool of 2048K of external SPI memory to heap allocator
I (697) spi_flash: detected chip: generic
I (701) spi_flash: flash io: dio
W (705) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (718) sleep: Configure to isolate all GPIO pins in sleep state
I (725) sleep: Enable automatic switching of GPIO sleep configuration
I (732) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (752) main: Starting
I (752) gpio: GPIO[36]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1762) lcdperif: Initializing Intel 8080 bus
I (1762) lcdperif: Install LCD driver of r61529
I (1762) gpio: GPIO[37]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1772) lcdperif: 0x3fc948c4 0x3fce0bd8
I (1772) lcdperif: reset
I (1772) r61529: reset level: 0
I (2182) lcdperif: init
I (2502) lcdperif: after init
I (2502) main: disp_drv: 0x3fc9290c
I (2502) main: Allocating framebuffer (internal)
I (3502) main: Blitting framebuffer, color: 0x3A
I (3502) r61529: fb: 0x3fce0c14, size: 0xA000
I (6502) main: Blitting framebuffer, color: 0xA3
I (6502) r61529: fb: 0x3fce0c14, size: 0xA000
I (9502) main: Blitting framebuffer, color: 0x0
I (9502) r61529: fb: 0x3fce0c14, size: 0xA000
I (12502) main: Blitting framebuffer, color: 0xFF
I (12502) r61529: fb: 0x3fce0c14, size: 0xA000
I (14502) main: Allocating framebuffer (PSRAM, 16-byte aligned)
I (14502) main: Flushing cache
I (15502) main: Blitting framebuffer, color: 0x3A
I (15502) r61529: fb: 0x3de00a10, size: 0xA000
I (17502) main: Flushing cache
I (18502) main: Blitting framebuffer, color: 0xA3
I (18502) r61529: fb: 0x3de00a10, size: 0xA000
I (20502) main: Flushing cache
I (21502) main: Blitting framebuffer, color: 0x0
I (21502) r61529: fb: 0x3de00a10, size: 0xA000
I (23502) main: Flushing cache
I (24502) main: Blitting framebuffer, color: 0xFF
I (24502) r61529: fb: 0x3de00a10, size: 0xA000

Other items if possible

  • sdkconfig file (attach the sdkconfig file from your project folder)
    sdkconfig.txt

  • elf file in the build folder (note this may contain all the code details and symbols of your project.)
    app-template.elf.zip

  • coredump (This provides stacks of tasks.)

@espressif-bot espressif-bot added the Status: Opened Issue is new label Dec 14, 2021
@github-actions github-actions bot changed the title ESP32S3: LCD: DMA buffer in PSRAM doesn't work properly ESP32S3: LCD: DMA buffer in PSRAM doesn't work properly (IDFGH-6426) Dec 14, 2021
@JadedTuna
Copy link
Author

JadedTuna commented Dec 14, 2021

I tested the same situation but using esp_lcd_panel_io_tx_param instead, and the issue did not present (I did have to lower the amount of data sent significantly to 32 bytes (= 16 pixels), due to it using an internal buffer & polling). I then put the ..._tx_color function back, but left the transmission size at 32 bytes (= 16 pixels). The issue presents again, but this time slightly differently. First draw call is still not sent, while the second one produces the following:
2-bands

There are two bands of color, brown and blue. It seems as if the first transaction is not sent, and instead the two are grouped together and sent then, which is interesting, since even if they are batched, the latter should end up overwriting the former...

@huming2207
Copy link
Contributor

I also encountered a similar issue that on_color_trans_done in esp_lcd_panel_io_i80_config_t keeps getting called way earlier before the transfer is finished. At that time I haven't got time to investigate whether that's my bug or Espressif's bug and I went on doing something else instead.

You can try putting on a logic analyzer with one extra GPIO, toggle it in the on_color_trans_done, and see if that's before or after the transfer. If that GPIO is toggled before the xfer is finished then something may be wrong there.

@espressif-bot espressif-bot added Status: In Progress Work is in progress and removed Status: Opened Issue is new labels Dec 27, 2021
@suda-morris
Copy link
Collaborator

yes, i80 bus can't convey buffers from PSRAM at the moment, we're working on that for esp32s3.

@espressif-bot espressif-bot added Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally Resolution: Done Issue is done internally and removed Status: In Progress Work is in progress Resolution: NA Issue resolution is unavailable labels Jan 14, 2022
dskulina pushed a commit to playable-tech/esp-idf that referenced this issue Feb 4, 2022
dskulina pushed a commit to playable-tech/esp-idf that referenced this issue Feb 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally
Projects
None yet
Development

No branches or pull requests

4 participants