Yea as you can see in the video I linked HERE , It’s NOT any better in 2.0 IDE. Constantly having to re-select the correct board in between compiles and uploads. I too developed some shortcuts to lessen the hassle.
HTH
gl :-p
The situation apparenty got WORSE after board package 1.8.1.
I’m on 1.8.3 now (Arduino IDE 1.8.19 on Windows 10) and I can’t upload ANYTHING on the XIAO, unless I fumble with the reset pads.
Not even the double-tap works, I have to try many times keeping the pads shortened for longer time.
here, stuck at “Uploading” forever…
No problem with any other board, even SAMD51-based (like the M0 Mini)
Please @Baozhu help us… the XIAO is such a fine board (I have tens of them), but it’s unusable now
I can confirm that reverting to Board Package 1.8.1, firmware upload works much better, close to 100% success, tried with 3 different XIAO boards.
So while we wait for Seeed Studio to fix the issue (if ever), I would suggest installing the old v1.8.1 core.
Hi,
Just completed a project using the XIAO and Arduino IDE V2.0.3. I had to revert to Board Package 1.8.1 as I couldn’t upload at all. I got into a kind of rhythm testing, updating code, uploading and re-boot. However, it was basically a painful and frustrating exercise and probably took me twice as long as it would if it worked properly.
Any news from Seeed Studio yet on a fix for this? It makes the board almost unusable which is a real shame.
To repeat the symptoms (if it helps diagnose the problem):
- Re-boot Windows (I’m on W11) and, as long as you don’t edit too much or start running other apps/software, the XIAO is recognised.
- Roughly 90% of the time clicking upload doesn’t work on its own, you have to short the reset pads twice to get into bootloader mode. Frequently that too doesn’t work immediately. It DOES switch to bootloader mode but the IDE has, by then, failed. Clicking upload again usually works.
- This process works generally twice in a row. The third time the reset double short causes a rapidly flashing yellow LED and unknown device to Windows - Reboot time.
- A small percentage of the time, even after a re-boot, a double short fails to enter bootloader mode - possibly my technique is not good and I just do a reset but I’ve hit times when I’ve tried and had to re-boot 3 or more times before successfully entering bootloader mode.
- Another small percentage of the time the device will enter bootloader mode automatically on clicking upload and everything works perfectly. Strangely this seems to be happening more frequently although it’s infrequent enough that might just be my perception.
Notes:
-
Generally, when I re-boot, I delete the hidden COM devices from Device Manager as they seem to block the device from working correctly, even after a re-boot.
-
I find I have to disconnect and re-connect the XIAO after the re-boot to ensure it works.
-
I have an entirely new Mobo/CPU etc. since the first post of this problem so I don’t think it’s hardware.
-
I did migrate my Windows installation image rather than re-build though.
-
I’ve tried testing various USB ports and USB3 vs USB2.1 ports and found no difference.
It’s a great little device with masses of Flash at a great price so PLEASE make it easier to use!! @Baozhu??
Thanks
I have tried the majority of the suggestions given by the kind and helpful contributors on this forum. thank you very much for help. Sadly, nothing worked for me and I am at a point where I simply cannot upload code to the XIAO. I had purchased 3 of these devices a few years ago but find them basically useless if they cannot be programmed. I will begin using the Qt Py as a replacement as I have had great success with regards to the reliability of the Adafruit offerings. Too bad, I had great hopes for using the 'XIAO.
My seeeD xiao sense is not programming either I receive this message:
"
Library Adafruit nRFCrypto has been declared precompiled:
Using precompiled library in C:\Users\scrpa\AppData\Local\Arduino15\packages\Seeeduino\hardware\nrf52\1.1.8\libraries\Adafruit_nRFCrypto\src\cortex-m4\fpv4-sp-d16-hard
Sketch uses 130968 bytes (16%) of program storage space. Maximum is 811008 bytes.
Global variables use 15172 bytes (6%) of dynamic memory, leaving 222396 bytes for local variables. Maximum is 237568 bytes.
Upgrading target on COM13 with DFU package C:\Users\scrpa\AppData\Local\arduino\sketches\E716EBE2190AE198C5721767327A3137\PERIPHERAL_CODE_XIAO.ino.zip. Flow control is disabled, Single bank, Touch disabled
Failed to upgrade target. Error is: Serial port could not be opened on COM13. Reason: could not open port 'COM13': PermissionError(13, 'Access is denied.', None, 5)
Traceback (most recent call last):
File "dfu\dfu_transport_serial.py", line 113, in open
File "serial\serialwin32.py", line 33, in __init__
File "serial\serialutil.py", line 244, in __init__
File "serial\serialwin32.py", line 64, in open
serial.serialutil.SerialException: could not open port 'COM13': PermissionError(13, 'Access is denied.', None, 5)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "__main__.py", line 296, in serial
File "dfu\dfu.py", line 235, in dfu_send_images
File "dfu\dfu.py", line 157, in _dfu_send_image
File "dfu\dfu_transport_serial.py", line 115, in open
nordicsemi.exceptions.NordicSemiException: Serial port could not be opened on COM13. Reason: could not open port 'COM13': PermissionError(13, 'Access is denied.', None, 5)
Possible causes:
- Selected Bootloader version does not match the one on Bluefruit device.
Please upgrade the Bootloader or select correct version in Tools->Bootloader.
- Baud rate must be 115200, Flow control must be off.
- Target is not in DFU mode. Ground DFU pin and RESET and release both to enter DFU mode.
I hope my board is not broken! there is a blinking blue LED. It connects but it can communicate with the serial port.
any suggestion?
Hi there,
You need to be in bootloader mode(press reset twice -fast) a drive should be visible and available in the File explorer. Or you have the same com port open in another window or program. Fix those and it should work , The BLUE LED usually means a BLE connection Looks like bluefruit is Loaded on the Xiao and running, And your trying to use a different BSP also to compile and flash.?
HTH
GL 
PJ 
1 Like
Hello,
I’m encountering the same error on my Xiao ESP32S3 board when uploading a program. When I press the start button and then the reset button, the message “Device not recognized” appears, even though it was previously recognized as COM5 before I performed this action. The red LED is constantly lit and the orange LED is flashing.
Thank you in advance to anyone who can help.
The program is using 309,555 bytes (9%) of the storage space. The maximum capacity is 3,342,336 bytes.
Global variables are using 20,824 bytes (6%) of the dynamic memory, leaving 306,856 bytes for local variables. The maximum capacity is 327,680 bytes.
esptool v5.1.0
Serial port COM5:
Connecting…
A serial exception has occurred: Unable to configure the port, an error has occurred. Original message: PermissionError(13, ‘A device connected to the system is not functioning correctly.’, None, 31)
Note: This error originates from pySerial. It is unlikely to be caused by esptool itself, but rather by the hardware connection or drivers. For troubleshooting assistance, see:
Load failed: Load error: Exit code 1
Hi there,
SO , two things can happen…
WHen you go to bootloader mode the Port can change, Check that .
The other is do not have any other windows open or IDE window using the same port or you will get that error.
In you main Loop function Leave a small delay (50); in the code so the bootloader hook will work without changing the port.
HTH
GL 
PJ 
Hold the Boot Button and press and release the reset button, you should hear the windows gong too, then release the boot button. Look at available ports now you should see an additional port or the same one , and the code on the device is stopped.
1 Like
2 windows open is a good point… i didnt think of that one…
and of course… I always need to say lower your serial baud rate to 9600 to 19200, atleast when troubleshooting serial communication issues
the only reason for an excessivly high baud rate is if the serial communications subroutines is slowing your main process… in that case you should reconsider the need of a serial process…
I am assuming people requiring this level of performance are not asking questions on this forum… IMO