Bug Report: ESP32 Boots into Bootloader on LightBurn 2.0.05
Environment:
- Windows 10
- Generic ESP32 (off Amazon)
- CP2102 USB-UART adapter
- LightBurn v2.0.05
- FluidNC 3.7.13/Grbl 3.7
Description:
Connecting LightBurn 2.0.05 to the ESP32 often forces the device into UART bootloader mode. Behavior is inconsistent:
- Sometimes it boots normally
- Sometimes it goes straight to bootloader, displaying the following message in the console:
ets Jul 29 2019 12:21:46 rst:0x1 (POWERON_RESET),boot:0x1 (DOWNLOAD_BOOT(UART0/UART1/SDIO_FEI_REO_V2)) waiting for download - Timing (e.g., reconnecting quickly vs. waiting a few seconds) affects the outcome
This problem was also not present until we upgraded from Lightburn ~1.0.06, and has only manifested since we renewed our license to use 2.0.05 and other controllers do not exhibit this behavior. Firmware, wiring, and power have been ruled out as a result.
Observed behavior suggests:
DTR/RTS lines are being asserted in a way that triggers ESP32 download mode on connect/disconnect. Could also be caused by other changes to the way Lightburn 2.0.05 initalises connection to the controller.
Steps to Reproduce:
- Connect ESP32 via CP2102 USB to Windows 10 machine.
- Open LightBurn 2.0.05 and connect to the device.
- Observe the ESP32 either booting normally or going to bootloader.
- Reconnecting or waiting a few seconds affects outcome.
Notes:
- Other serial senders (UGS, CNCjs, etc.) do not trigger this behavior.
- Appears to be a regression in LightBurn’s serial port handling.
- We understand that by having somewhat of a homebrew set up, there very well may be a low reporting of this bug, but it can create some serious headaches if not addressed.
Please let me know if anyone else has experienced a similar bug, or if there is anything else we can try to root out this issue. It’s not machine breaking, but it concerns us that Lightburn is forcing our controller into bootloader mode, or any other boot mode other than right to the installed firmware.
