-
Notifications
You must be signed in to change notification settings - Fork 7.2k
-
Notifications
You must be signed in to change notification settings - Fork 7.2k
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
Comments
I also encountered a similar issue that You can try putting on a logic analyzer with one extra GPIO, toggle it in the |
yes, i80 bus can't convey buffers from PSRAM at the moment, we're working on that for esp32s3. |
Environment
git describe --tags
to find it): v5.0-dev-676-g5c33570524xtensa-esp32-elf-gcc --version
to find it): xtensa-esp32-elf-gcc (crosstool-NG esp-2021r2) 8.4.0Problem 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 usingheap_caps_aligned_alloc(16, ...)
. Between each render call buffer ismemset
with a value, and the cache flushed usingCache_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:
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).
Code to reproduce this issue
Minimal example
Debug Logs
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.)
The text was updated successfully, but these errors were encountered: