I have an update to share on this subject: Since I wasn't able to reproduce the fault, I have not escalated this to the serial-discovery developers. However, we did receive another report of an ESP32-related problem, which I was able to reproduce:
I am new to Arduiino and just following the instruction in the plug and make kit.
All was well until one day it just would not connect. The LED matrix no longer shows ant attempt to connect to the cloud. USB link fails even though it revognises tge board is there. I get one green LED only. If i do a reset it flashes yellow.
I have tried all self help and ESP flash.
Stillnot working
Thanks to your report here, I eventually settled on the hypothesis that the cause of that fault was interference from serial-discovery 1.5.0. Sure enough, this was supported by the results of my experiments. I have submitted a formal report to the developers about serial-discovery 's interference with the process of flashing the firmware to the ESP32-S3-based "bridge" module on the UNO R4 WiFi:
opened 07:11AM - 14 Jul 26 UTC
topic: code
type: imperfection
### Describe the problem
When **serial-discovery** is running, the process of f… lashing the firmware to the "bridge" connectivity module on the UNO R4 WiFi board may fail:
```text
$ bin/espflash write-bin -b 115200 0x0 firmware/UNOR4-WIFI-S3-0.6.0.bin
[2026-07-14T06:02:00Z INFO ] 🚀 A new version of espflash is available: v4.5.0
[2026-07-14T06:02:00Z INFO ] Serial port: 'COM5'
[2026-07-14T06:02:00Z INFO ] Connecting...
[2026-07-14T06:02:01Z INFO ] Using flash stub
Chip type: esp32s3 (revision v0.1)
Crystal frequency: 40MHz
Flash size: 8MB
Features: WiFi, BLE
MAC address: dc:54:75:c4:c6:54
Error: x The bootloader returned an error
|-> Error while running FlashDeflateData command
`-> Bad data checksum
```
This leaves the board in a soft bricked state where it is not possible to upload to the primary RA4M1 microcontroller.
### To reproduce
#### Equipment
- UNO R4 WiFi board
#### Steps
1. If the UNO R4 WiFi board is already connected to your computer, unplug the cable.
**ⓘ** I find the fault only occurs if the board has been plugged after a `START_SYNC` command has been run in a `serial-discovery` instance.
1. Invoke `serial-discovery`.
1. Run the [`HELLO` command](https://arduino.github.io/arduino-cli/dev/pluggable-discovery-specification/#hello-command):
```text
HELLO 1 "arduino-cli 1.5.1"
```
1. Run the [`START_SYNC` command](https://arduino.github.io/arduino-cli/dev/pluggable-discovery-specification/#start_sync-command):
```text
START_SYNC
```
1. Repeat the above steps a couple more times.
**ⓘ** I am able to produce the fault even with only a single `serial-discovery` instance, but only intermittently. I find that having multiple instances allows the fault to be reproduced reliably.
1. Make any preparations for flashing the "bridge" firmware on an UNO R4 Board.
You can use the low level approach of working with [**espflash**](https://github.com/esp-rs/espflash) directly:
https://support.arduino.cc/hc/en-us/articles/16379769332892-Restore-the-USB-connectivity-firmware-on-UNO-R4-WiFi-with-espflash
Or (if you haven't already soft bricked the board), using [**Arduino Firmware Uploader**](https://arduino.github.io/arduino-fwuploader/):
https://support.arduino.cc/hc/en-us/articles/9670986058780-Update-the-connectivity-module-firmware-on-UNO-R4-WiFi#cli
1. Connect the UNO R4 WiFi board to your computer with the USB cable.
1. Attempt the firmware update.
1. If the update is successful, try again. I have found that the fault can be intermittent, so it may not occur on the first try.
🐛 The update attempt fails.
### Expected behavior
**serial-discovery** does not interfere with updates of the firmware on the UNO R4 WiFi's connectivity module.
### serial-discovery version
1.5.0
### Operating system
Windows
### Operating system version
11
### Additional context
I am not able to reproduce the fault with **serial-discovery** 1.4.3.
---
At first glance, the use of multiple instances of **serial-discovery** in the demo might seem unrealistic. However, this can occur in real life usage in the case where multiple official development tools are running simultaneously:
- Arduino IDE
- Arduino Create Agent
- Arduino App Lab
---
We have also received some reports of 1.5.0 specifically interfering with standard sketch uploads to ESP32 targets:
- https://forum.arduino.cc/t/serial-discovery-1-5/1451662
- https://forum.arduino.cc/t/esp32-wroom-da-module-need-flash-mode-qout/1451488
However, I have not been able to reproduce those.
---
The fault also occurs when attempting to update the firmware via ["**Firmware Updater**" feature](https://docs.arduino.cc/software/ide-v2/tutorials/ide-v2-fw-cert-uploader#firmware-updater) of Arduino IDE. I also find that firmware update attempts made via Arduino Cloud fail. However, the opaque design of that service does not give me insight into the nature of the failure, so it might have a different cause.
---
Originally reported at https://forum.arduino.cc/t/uno-r4-wifi-stopped-working-after-1-week/1425480
<a name="workaround"></a>
#### Workaround
Close Arduino IDE, Arduino Create Agent, and Arduino App Lab, then flash the firmware via [**Arduino Firmware Uploader**](https://arduino.github.io/arduino-fwuploader/):
https://support.arduino.cc/hc/en-us/articles/9670986058780-Update-the-connectivity-module-firmware-on-UNO-R4-WiFi#cli
Or directly:
https://support.arduino.cc/hc/en-us/articles/16379769332892-Restore-the-USB-connectivity-firmware-on-UNO-R4-WiFi-with-espflash
---
### Issue checklist
- [X] I searched for previous reports in [the issue tracker](https://github.com/arduino/serial-discovery/issues?q=)
- [X] My report contains all necessary details
I suspect that the mechanism causing that fault is the same as the one causing the upload error you encountered. If so, the fix for the arduino/serial-discovery#128 should also resolve the upload error you are encountering.
I believe this is the change that caused the regression:
main ← usb_fields
opened 01:31PM - 19 May 26 UTC
This PR adds the following fields derived from USB descriptors:
* `configurat… ion`
* `manufacturer`
* `product`
to the port add/remove message.
This results in serial-discovery actively querying the USB device. It seems like maybe that querying may cause interference with other processes accessing the same device under certain conditions.