Multiple Commands in Sequence Cause the ESP32 to Crash and Restart

[joshua137k]

I'm facing a problem with my project using the ESP32. Whenever I try to draw a slightly larger graphic, the ESP32 crashes and restarts. I'm not sure if the issue lies in my code or if it's a limitation of the libraries I'm using.

I've tested with both the GFX and Composite libraries, but both result in the same error. It seems that multiple commands in sequence are causing this undesirable behavior.

To better illustrate the problem, I'll share a video showing what happens and also the link to my project.

Any help to resolve this issue would be greatly appreciated.

https://github.com/joshua137k/ARDUINOGAMEBOY
https://youtube.com/shorts/nLURCmd-DlE

[Roger-random]

Thank you for sharing those links. Here are my initial thoughts:

After watching the YouTube clip:

• When an ESP32 restarts like that, there's usually an error message with stack track sent to serial monitor. It's fairly cryptic. For human-readable information, it needs to be fed into an exception decoder such as https://github.com/me-no-dev/EspExceptionDecoder Hopefully it will add more information for troubleshooting.

• The visual noise indicates only one of two buffers are being drawn on. To eliminate flicker, this library uses double buffering: when one is being displayed, the other is available for drawing. Calling waitForFrame() swaps the drawing buffer with the display buffer reversing their roles. As a result, getFrameBufferLines() need to be called after every waitForFrame() so the correct frame buffer is used.

Skimming GitHub project code:

• I see references to ESP32 WiFi stack. The composite video generation code from ESP_8_Bit pushes ESP32 up to limit of its capabilities, there's not much left to handle WiFi. Trying to do both WiFi and composite video will be difficult, possibly causing the crash. If WiFi capability is a must, I recommend looking at the "ESPFLIX" project by the same author who created ESP_8_BIT. ESPFLIX added WiFi capabilities to their composite video display mechanism, but they had to make tradeoffs for it to happen. https://github.com/rossumur/espflix

Hope this helps!

[joshua137k]

Thank you for the response, Roger.

After investigating further based on your suggestions, I used the EspExceptionDecoder to decode the error messages from the serial monitor. I found that the ESP32 was attempting to access a non-existent reference, causing the crash. This seemed to occur due to the combined use of the graphics library and WiFi, overloading the ESP32.

I agree that the problem is related to the simultaneous use of WiFi and the graphics library. From what I understand, this combination is too much for the ESP32 to handle, leading to the system reboot. For now, I will not explore the ESPFLIX project. I will try to manage the integration with the SDCard and focus on creating a fixed control.

However, I still have difficulty understanding the interaction between waitForFrame() and getFrameBufferLines(). Even when calling getFrameBufferLines() after waitForFrame(), I continue to experience visual noise. I do not fully understand how these functions should be used to avoid this issue. If you could provide more details or an example of how to use these functions, it would be very helpful.

Once again, thank you for your guidance.

[Roger-random]

Visual noise like those shown in your video displayed uninitialized data. You're seeing noise because your code never drew in those locations. Adding calls to getFrameBufferLines() allows access to both buffers, but you still have to draw on those buffers to change them from noise to your application content.

Calling fillScreen(0) will clear the buffer to zero (black). You can see the implementation in void ESP_8_BIT_GFX::fillScreen(uint16_t color)

ESP_8_BIT_composite/ESP_8_BIT_GFX.cpp

Line 460 in 610ca84

void ESP_8_BIT_GFX::fillScreen(uint16_t color)