Programming of ESP8266 mini with IDE 18.19 works correctly but
(tested different versions 2.3.x)
Same computer, same USB Port!
Tested different solutions with
settings are the same in version 1.8.19 and 2.3.10 (also installed library for 8266)
ERROR:
With Arduino 1.8.19 the target programming works perfectly and the ESP8266 mini works fine!
What is here the problem of arduino version 1.8.19 and 2.3.x
I more than likely can not help you but I have a question.
Is the IDE 1.8.19 a portable installation? If so, the ESP8266 board package might be different.
It's not a library
I installed the version 2.3.10 with library ESP8266 not working
then I tried the legacy version 1.8.19 installed on the same computer (windows 11) with
version 1.8.19 works, version 2.3.10 NOT
and yes I tried different sketch and I tried also different ESP8266 mini modules
I also installed the version 2.3.10 on a laptop (windows10), also not working, with
Hi @torquayn . I believe you are being affected by the bug tracked here:
opened 02:23AM - 09 Jul 26 UTC
topic: code
type: imperfection
### Describe the problem
After updating to arduino-cli 1.5.1 and serial-discov… ery 1.5.0 on Windows 11,
ESP32 uploads consistently fail with checksum errors during stub flasher upload:
```
A fatal error occurred: Failed to write to target RAM (result was 0107: Checksum error)
```
### To reproduce
### Prerequisites
- Windows 11 (any edition)
- Arduino IDE 2.x with arduino-cli 1.5.1+ and serial-discovery 1.5.0+
- ESP32 board package 3.3.10 (or any version using esptool 5.x)
- An ESP32 dev board with FTDI USB-to-Serial chip (e.g., ESP32-DevKitC, NodeMCU-32S)
- A minimal Arduino sketch (e.g., BareMinimum or Blink)
### Reproduce via Arduino IDE
1. Open Arduino IDE 2.x
2. Connect an ESP32 board via USB
3. Select the correct board and COM port in the IDE
4. Open any sketch (e.g., File → Examples → 01.Basics → BareMinimum)
5. Click **Upload** (Ctrl+U)
6. **Observe**: Upload fails with one of:
- `Failed to write to target RAM (result was 0107: Checksum error)`
- `Serial data stream stopped: Possible serial noise or corruption`
### Reproduce via arduino-cli (standalone)
```bash
# 1. Create a minimal sketch
mkdir C:\Temp\TestSketch
echo "void setup(){} void loop(){}" > C:\Temp\TestSketch\TestSketch.ino
# 2. Attempt upload via arduino-cli
arduino-cli compile \
--fqbn "esp32:esp32:esp32:UploadSpeed=115200,FlashSize=4M" \
--upload --port COM5 \
C:\Temp\TestSketch\TestSketch.ino
# 3. Observe the checksum error
# Expected output:
# Connecting.....
# Connected to ESP32 on COM5:
# Chip type: ESP32-D0WD-V3 (revision v3.1)
# Uploading stub flasher...
# A fatal error occurred: Failed to write to target RAM (result was 0107: Checksum error)
```
### Verify the Upload Command Itself Is Correct
```bash
# The SAME flasher command works when run directly (not spawned by arduino-cli):
"C:\Users\<user>\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.3.10\tools\flasher.exe" \
--esptool "...\esptool.exe" \
--build-dir "<build_path>" \
--no-fast-flash \
--chip esp32 --port COM5 --baud 115200 \
--before default-reset --after hard-reset \
write-flash -z --flash-mode keep --flash-freq keep --flash-size keep \
0x1000 bootloader.bin 0x8000 partitions.bin 0xe000 boot_app0.bin 0x10000 sketch.bin
# Result: Upload succeeds, all binaries written, Hash verified
```
### Reproducibility
- 100% reproducible when upload is triggered through `arduino-cli` (either via IDE or CLI)
- 0% reproducible when the identical `flasher.exe` command is run directly from a shell
- Affects 2 out of 2 tested ESP32 boards (different physical units)
- Persists across USB cable and USB port changes
### Expected behavior
The `arduino-cli compile --upload` command should successfully upload firmware to the ESP32 board, identical to running `flasher.exe` directly.
Specifically:
1. **Stub flasher upload to RAM should succeed** — esptool should be able to upload the stub flasher to the ESP32's internal RAM via the ROM bootloader's `mem_begin`/`mem_block`/`mem_end` commands without checksum errors.
2. **Flash write should complete** — After stub upload, esptool should erase and write the firmware binary to SPI flash at the target addresses (0x1000, 0x8000, 0xe000, 0x10000).
3. **Hash verification should pass** — The written data should match the source binary, confirmed by SHA-256 hash verification.
4. **Hard reset should work** — The ESP32 should be reset via RTS pin after flashing, and the uploaded sketch should begin executing.
5. **Consistent behavior** — The upload should succeed regardless of whether `flasher.exe` is spawned by `arduino-cli` or invoked directly from a shell, since the underlying `esptool` arguments are identical in both cases.
---
## Actual Behavior
1. **Stub flasher upload fails** — During the `mem_block` data transfer (SLIP-encoded binary upload to ESP32 RAM), the ESP32 ROM bootloader computes an XOR checksum of received bytes. The computed checksum does not match the transmitted checksum, indicating data corruption on the wire.
2. **Error code 0107** — The ESP32 ROM bootloader returns error `0x0107` ("Checksum error"), which esptool reports as `Failed to write to target RAM (result was 0107: Checksum error)`.
3. **Intermittently changes to timeout** — In some runs, instead of a checksum error, the communication stops entirely with `Serial data stream stopped: Possible serial noise or corruption`.
4. **Only fails when spawned by arduino-cli** — The exact same `flasher.exe` command line, when executed directly from `cmd.exe` or `bash`, completes successfully with all data verified.
### Arduino CLI version
arduino-cli 1.5.1 (2026-06-05)
### Operating system
Windows
### Operating system version
Windows 11 Home China 10.0.26200
### Additional context
#### Root Cause Hypothesis
`arduino-cli` v1.5.1 on Windows opens the target COM port for board detection/verification before spawning `flasher.exe`. Due to Windows process handle inheritance (the default behavior of `CreateProcess` with `bInheritHandles=TRUE`), the child `flasher.exe` process inherits the already-open COM port handle. When both the parent (`arduino-cli`) and child (`flasher.exe` → `esptool`) have an open handle to the same COM port, data transmitted through the SLIP protocol becomes corrupted, causing the ROM bootloader's XOR checksum validation to fail.
This is consistent with the observation that:
- Direct `flasher.exe` invocation (no inherited handle) always succeeds
- The issue appeared after `serial-discovery` v1.5.0 started polling COM ports more aggressively, increasing the probability and duration of COM port handle conflicts
- Linux is unaffected because `fork()`+`exec()` allows explicit control of file descriptor inheritance
#### Workaround
1. Compile without upload: `arduino-cli compile sketch`
2. Run flasher directly to upload (see `upload.bat` in the project directory)
#### Related
- `serial-discovery` was updated from 1.4.3 to 1.5.0 around the same time this issue appeared, which may have changed COM port polling frequency and exacerbated the handle conflict.
- `arduino-cli` v1.5.1 (released 2026-06-05) may have introduced changes to child process spawning or COM port management.
#### Additional reports
- https://forum.arduino.cc/t/serial-discovery-1-5/1451662
- https://forum.arduino.cc/t/esp32-wroom-da-module-need-flash-mode-qout/1451488
- https://forum.arduino.cc/t/programming-of-esp8266-mini-with-arduino-2-3-does-not-work/1452130
### Issue checklist
- [x] I searched for previous reports in [the issue tracker](https://github.com/arduino/arduino-cli/issues?q=)
- [x] I verified the problem still occurs when using the [nightly build](https://arduino.github.io/arduino-cli/dev/installation/#nightly-builds)
- [x] My report contains all necessary details
That bug is caused by a helper tool used by Arduino IDE 2.x, which is named serial-discovery
The developers have already prepared a fix for that bug. I'll provide instructions you can follow to replace the bad installation of serial-discovery with the fixed version:
If Arduino IDE 2.3.10 is running, select File > Quit from the Arduino IDE menus.
Start Windows File Explorer .
Use File Explorer to navigate to the folder at the following path on your computer's hard drive:C:\Users\<username>\AppData\Local\Arduino15\packages\builtin\tools\serial-discovery\1.5.0
<username> is your Windows username)
AppData folder is hidden by default. You can make it visible by opening the "View " menu in File Explorer , then checking the box next to "☐ Hidden items ".
You will see a file named serial-discovery.exe in the folder. Right click on that file.
Select "Rename " from the menu.
Type serial-discovery-original in the text field.
Press the Enter
Click the following link to download the fixed version of serial-discovery :serial-discovery_test-13c959e7be4f01527db4d60fbabfa180616cf0c8-git-snapshot_Windows_64bit.zip (2.2 MB)
Wait for the download to finish.
Extract the downloaded serial-discovery_test-13c959e7be4f01527db4d60fbabfa180616cf0c8-git-snapshot_Windows_64bit.zip file to any convenient location on your computer.Copy the serial-discovery.exe file from the extracted folder to the folder at the following path on your hard drive:C:\Users\<username>\AppData\Local\Arduino15\packages\builtin\tools\serial-discovery\1.5.0
<username> is your Windows username)
Now start Arduino IDE 2.3.10 and try uploading again, just as you did before when you encountered the error. Hopefully it will be successful this time.
Please let us know if you have any questions or problems while following those instructions. Please also post a reply here to let us know if this does fix the error for you. That feedback will be very useful for validating the fix. We are not able to reproduce the error, so we are dependent on the feedback from affected users like you.
Hello ptillisch
THX for your help, thats was the problem, it compiles and writes the sketch on the ESP8266
Thanks for you great help
You are welcome. I'm glad it is working now.
Thanks so much for taking the time to post an update. I notified the developer of the results of your test of the prospective fix they prepared.
Regards, Per
Unless we're talking about different things).
The