Waveshare ESP32-S3 Touch LCD 2 camera hangs after IDF 5.5 update

[oroderico]

I’m investigating camera/touchscreen hangs on the Waveshare ESP32-S3 Touch LCD 2 board after the IDF 5.5 update.

Hardware tested:

• Waveshare ESP32-S3 Touch LCD 2
• OV5640 camera
• Config: configs/sdkconfig_display_waveshares3_touch_lcd2.defaults
• ESP-IDF: 5.5.4

Observed behavior:

• The device can hang on the Jade DIY boot screen.
• The QR scanner can stay stuck at Initializing....
• Exiting the camera can freeze the device.

Regression point found during testing:

• 52ab757c before the IDF 5.5 update: boots successfully
• d931d543 after the IDF 5.5 update: hangs at the Jade DIY boot screen

This suggests the issue was exposed by the IDF 5.5 update, likely through the camera/touchscreen lifecycle on this board.

Investigation branch:
https://github.com/oroderico/Jade/tree/investigate-waveshare-s3-camera-hangs

What I found:

• During boot, boot_process() calls jade_camera_process_images(..., show_ui=false, ...) to feed random entropy from the camera.
• On this board, that happens after touchscreen/input initialization.
• jade_camera_init() and jade_camera_stop() currently restart the touchscreen whenever CONFIG_DISPLAY_TOUCHSCREEN is enabled.
• On the Waveshare ESP32-S3 Touch LCD 2, the touchscreen and camera use separate I2C buses/pins, so restarting the touchscreen around camera start/stop does not seem necessary.
• That touchscreen restart path appears to be where the hangs happen.
• The board backlight was also using LEDC timer/channel 0/0, while the camera config also references LEDC timer/channel 0/0. Moving the backlight to another LEDC timer/channel avoids that resource overlap.

The investigation branch contains a minimal board-specific test patch:

• Skip boot-time camera entropy for CONFIG_BOARD_TYPE_WS_TOUCH_LCD2.
• Do not restart the touchscreen around camera start/stop for CONFIG_BOARD_TYPE_WS_TOUCH_LCD2.
• Move the Waveshare backlight PWM from LEDC timer/channel 0/0 to timer 1/channel 7.

With that branch tested on hardware:

• Boot passes the Jade DIY screen.
• Camera scanner opens.
• Camera no longer stays stuck at Initializing....
• Exiting the camera no longer freezes.
• Re-opening the camera works.

I’m opening this as an issue first because the patch works on hardware, but I’d like feedback on whether this is the preferred direction or if the touchscreen/camera lifecycle should be handled differently for this board.

cc @CaTeIM in case he wants to follow the investigation.

[jgriffiths]

Hi @oroderico The approach looks good, I would split each change into a single commit with the commit description explaining the rationale for the change. That will be better for debugging/testing I think, and the commit history will be useful for future peeps.

[CaTeIM]

Great investigation @oroderico, the touchscreen restart path was indeed the right suspect. I audited every commit since 1.0.39 to pin this down.

Root Cause

• The regression bisects to a single commit: d931d543 (esp-idf: update to v5.5.4). The mechanism is an undocumented breaking change in IDF 5.5, not the camera and not LEDC.
• Since IDF v5.5.0 (espressif/esp-idf@e73d78ba), i2c_del_master_bus() refuses to delete a bus that still has devices attached and returns ESP_ERR_INVALID_STATE ("Cannot delete I2C bus(0): devices are still attached, please remove all devices and then delete bus"). Under v5.4 it destroyed the bus unconditionally.
• The touchscreen task registers a device on its i2c bus via esp_lcd_new_panel_io_i2c() (main/input/touchscreen.inc:57) but never releases it, so under 5.5.4 the first touchscreen_deinit() fails at ESP_ERROR_CHECK(_i2c_deinit(...)) (touchscreen.inc:94) and aborts.
• This board panics with CONFIG_ESP_SYSTEM_PANIC_PRINT_HALT=y, so it halts frozen on whatever is on screen.
• The only callers of touchscreen_deinit()/init() are jade_camera_init()/jade_camera_stop() (main/camera.c:323-337), which covers all three symptoms: boot entropy (splash), scanner stuck at "Initializing...", and the freeze when leaving the camera.

Notes on the test patch

• LEDC timer/channel move: No effect on ESP32-S3: esp32-camera v2.0.15 generates XCLK via the LCD_CAM peripheral and never touches LEDC on this target (xclk.c isn't even compiled for S3), so the backlight overlap is harmless.
• Skipping boot camera entropy: Not needed. With the deinit fixed, boot entropy works normally.
• Skipping the touchscreen restart on this board: Valid (separate buses), but becomes optional once the root cause is fixed.

Fix (tested on hardware)

• Release the touch handle and the panel IO device (which removes it from the bus) before deleting the bus:

    // Since IDF 5.5 the i2c bus cannot be deleted while devices are still attached
    ESP_ERROR_CHECK(esp_lcd_touch_del(ret_touch));
    ESP_ERROR_CHECK(esp_lcd_panel_io_del(tp_io_handle));
    ESP_ERROR_CHECK(_i2c_deinit(touch_i2c_handle));

• Result: Restores the deinit/init cycle for all touchscreen boards, including M5CoreS3 (where the restart is load-bearing since camera and touch share i2c pins), and also fixes a per-cycle heap leak that already existed under 5.4.
• Tested on my Waveshare S3 Touch LCD 2: boot passes the splash, the scanner opens and scans, exiting and re-opening the camera works, and touch keeps working afterwards.

Additional finding (M5CoreS3)

• The same IDF change breaks M5CoreS3 earlier in boot: power_init() attaches the axp2101/aw9523 devices and then calls _i2c_deinit(NULL) with them still attached (main/power/m5stackcores3.inc:44-51), which now fails before the display comes up.
• I don't own that board, so I left it out of the PR.

@jgriffiths PR opened with this as a single commit: #307. Happy to open a separate PR with the analogous M5CoreS3 fix if you think it's worthwhile.

@oroderico if you can give #307 a run on your board as well, extra hardware confirmation always helps.

[jgriffiths]

@CaTeIM thanks for confirming the root cause/minimal fix. I'm happy to take the M5CoreS3 fix - better than leaving someone else to debug it even if we can't directly test currently. Thanks!

[jgriffiths]

Closing, @CaTeIM please feel free to push the M5CoreS3 fix and I'll merge after review, thanks!