Any known issues with readRect() to read screen data?

[revolt-randy]

As the title states, I am having problems with the readRect() function, but it is a complex problem.

I wrote a library to draw a pop-up window on my display. The library uses readRect() to read the screen data before drawing the pop-up window. When the pop-up window should be erased from the display, I use pushRect() to re-draw the area of the screen where the pop-up window was. The code works great and I'm attaching it here.
warning_test.zip

The problem I am having is when I add that library to my main project, which is kind of complex. When my project calls the readRect(), it crashes the ESP32. The crash produces an error message with a backtrace, see here - https://www.esp32.com/viewtopic.php?f=19&t=19355 According to that data, my code was crashing on a task I have running on core0. When I disable the code running on core0, now when the crash occurs, it's a WDT reset. So I'm a bit confused as to what is happening.

Anyone have any idea what might be going on here?

I do have a debugger on order and I am switching to PlatformIO IDE to look into this problem, but if anyone has any advice, I'd love to hear it!

Thanks
Randy

[Bodmer]

This sounds like a memory issue since it worked in a simpler environment. Screen buffers take a lot of memory. Make sure you can reserve enough space for the readRect data.

Note that if you are trying to run RTOS tasks (or use TFT_eSPI across both processors) that TFT_eSPI is not thread safe.

[revolt-randy]

Thanks for the reply! I was thinking memory issue too, but after further testing, I'm not so sure that it's a memory problem. I'm using the ESP32's huge_app.cvs partition scheme, compiled it's using 10% ram and 35% flash memory. The size of the screen I'm trying to copy is 160x140 pixels, which would use 22.4k of memory. So I should have enough room to store that data.

I do have code running on both cores, but all the code is separated and not shared between cores. I have experienced crashes when I tried to share code between the cores, and learned to keep the code between the cores separated. My current problem is not that kind of crash that you get when trying to share code between cores.

I'm still looking into the problem, but it does appear to be a problem after my call to readRect(). So it's probably my code and not your library that is causing the crash. Currently, I'm getting a WDT reboot after the readRect() call and a couple of other lines of code execute.

Is there any way to trace what triggers a WDT reboot?

[Bodmer]

Each pixel requires 2 bytes so the memory demand will be 44.8kBytes. The problem is that memory can get "fragmented" and if two functions both want large memory areas then one request may fail. There are various functions that allow memory space to be monitored. One way around this is to reserve a global memory area for the screen buffer (i.e. do not create and destroy the buffer locally in a function) and see if your sketch runs.

If your processor board has PSRAM fitted then you could use this for the screen buffer. The sprite creation automatically uses the PSRAM memory if it is available and enabled, see here. So PSRAM memory could be reserved via createSprite() or in your own sketch, this keeps bulk memory requests off the main memory stack.

As you can imagine there is little I can do to change the situation.

[revolt-randy]

"Each pixel requires 2 bytes so the memory demand will be 44.8kBytes."

This is the problem, I was a bit confused about the data type and size of the buffer. I was defining the buffer like so:
uint16_t _screenData[_xSize * _ySize] PROGMEM; // screen data buffer
Which in my case, defined the buffer to be 22.4k, (1 byte per pixel), or half the size of what is really needed. Changing the definition to:
uint16_t _screenData[2 * (_xSize * _ySize)] PROGMEM; // screen data buffer
Creates the correctly sized buffer, and the code works without any problems.

Thank you for the discussion, and a bigger thank you for the library!