Unable to consistently upload to xiao esp32c3

Development Tools Uploading
1

It's been several weeks since I last used the Arduino IDE. This morning, when I opened it, it wanted to update, so I did. Now, I am consistently unable to upload code to xiao esp32c3 boards. I have been able to do so before, and can't think of what might be causing this, except for some change from the update.

The issue persists across combinations of different cables and boards(both in a circuit and completely unconnected to anything), so I do not believe it is a hardware issue, or a problem with a specific board.

The code I am using is just the blink example sketch with #define LED_BUILTIN 4 added before the setup.

Very rarely, it will complete the upload, but in the vast majority of cases, it will fail. Shown below is an error message.

Sketch uses 254152 bytes (19%) of program storage space. Maximum is 1310720 bytes.
Global variables use 11780 bytes (3%) of dynamic memory, leaving 315900 bytes for local variables. Maximum is 327680 bytes.
"C:\Users\ziadn\AppData\Local\Arduino15\packages\esp32\tools\esptool_py\4.6/esptool.exe" --chip esp32c3 --port "COM10" --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_mode keep --flash_freq keep --flash_size keep 0x0 "C:\Users\ziadn\AppData\Local\arduino\sketches\16D1FF072F731880C53DFD9C0821CBF0/Blink.ino.bootloader.bin" 0x8000 "C:\Users\ziadn\AppData\Local\arduino\sketches\16D1FF072F731880C53DFD9C0821CBF0/Blink.ino.partitions.bin" 0xe000 "C:\Users\ziadn\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.7/tools/partitions/boot_app0.bin" 0x10000 "C:\Users\ziadn\AppData\Local\arduino\sketches\16D1FF072F731880C53DFD9C0821CBF0/Blink.ino.bin"
esptool.py v4.6
Serial port COM10
Connecting...
Chip is ESP32-C3 (revision v0.4)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 64:e8:33:85:b6:04
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00004fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x00050fff...
Compressed 18688 bytes to 12099...
Writing at 0x00000000... (100 %)
Wrote 18688 bytes (12099 compressed) at 0x00000000 in 0.3 seconds (effective 547.4 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 146...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (146 compressed) at 0x00008000 in 0.0 seconds (effective 629.3 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 686.8 kbit/s)...
Hash of data verified.
Compressed 265120 bytes to 147030...
Writing at 0x00010000... (11 %)
Writing at 0x0001bc15... (22 %)
Writing at 0x00023ba0... (33 %)
Writing at 0x0002a283... (44 %)
Writing at 0x0003054a... (55 %)
Writing at 0x00036830... (66 %)
Writing at 0x0003ce9f... (77 %)
Writing at 0x000449cd... (88 %)
Writing at 0x0004a649... (100 %)
Traceback (most recent call last):
File "esptool_init_.py", line 1064, in main
File "esptool_init.py", line 859, in main
File "esptool\cmds.py", line 595, in write_flash
File "esptool\loader.py", line 131, in inner
File "esptool\loader.py", line 1032, in flash_defl_block
File "esptool\loader.py", line 435, in check_command
File "esptool\loader.py", line 404, in command
File "esptool\loader.py", line 337, in read
StopIteration
A fatal error occurred: The chip stopped responding.
Failed uploading: uploading error: exit status 2

The terminating error is either as shown or

A fatal error occurred: Packet content transfer stopped (received 0 bytes)
Failed uploading: uploading error: exit status 2

, but it doesn't always happen in the same place. Sometimes it comes after "stub running", sometimes in the middle of the "writing at..." messages, and sometimes at the end. Both means of entering bootloader mode have no effect. Once in a blue moon it will upload successfully, but not in a repeatable manner.

I've tried looking online, but can't find anything helpful given that this issue is occurring with multiple brand new boards, not connected to anything, not even pin headers.

any help would be greatly appreciated. Thank you.

2

XIAO ESP32C3, Win11-pro, ESP32 core 3.0.7, IDE 2.3.4
Board selection: XIAO_ESP32C3, COM10, default settings.
Tried to upload several times with a medium-size email sketch, no problems.
Leo..

3

I’ve had ocassional issues uploading to my ESP32C3. Try holding down the BOOT button and press RESET. Release both them try re-uploading.

5

I am very curious as to what exactly you think I meant by “BOTH means of uploading bootloader mode have no effect.”

6

Hi @omnia_et_nihil. This error might be caused by the communication lines between the computer and the microcontroller on the board not being able to support the rather high default upload speed. If so, the problem should be fixed by reducing the upload speed, which is configurable via a convenient menu.

Select Tools > Upload Speed > 115200 from the Arduino IDE menus and then try uploading the sketch again, just as you did before. Hopefully this time the upload will be successful. If not, add a reply here on the forum thread to let us know and we'll investigate further.

Optimizing Upload Speed

If the sketch upload no longer failed after reducing the upload speed, you will have determined that the board is not capable of managing uploads at the default 921600 baud, but is capable of them at 115200 baud.

Especially with more complex sketches, the upload will take a significant amount of time at 115200 baud. It is likely that the board is capable of managing uploads at some speed higher than 115200 baud, so it is worth doing some experimentation to determine the maximum speed at which you can reliably upload to the board. You can do this by repeating the "Configure Upload Speed" procedure above, but selecting different speeds each time. Then attempting an upload to see if the new speed is appropriate.

7

That had no effect.

8

Tried that. It had no effect.

9

Like "bwinter" I had similar issue quite some times. Not with new XIAO ESP32C3, but after some time. I found out that due to some errors in the Serial codes at some examples, the chip hinders its serial communication. As simple as it sounds, indeed "hold boot - push reset - release boot" did solve the issue.

10

Which as I A: stated in the original post and B: further emphasized to the first guy, is something I already tried.

Can you people not read?

11

Please keep it civil when people only want to help.

Maybe you should try to re-flash the board with the factory's bootloader.
Bottom of this page.
Leo..

12

It wasn’t clear who you were responding to, so your follow-up comments weren’t clear on what you were communicating.