[macOS] ESP32-MINI-1 module gives Guru Meditation Error when stub is uploaded using esptool-js, and Failed to write to target RAM in esptool 4.8.1/4.9.0 (ESPTOOL-1000)

[tyeth]

Operating System

macOS 15.3

Esptool Version

4.8.1

Python Version

3.11.7

Chip Description

ESP32-MINI-1 [ESP32-U4WDH (revision v3.1) Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None]

Device Description

Adafruit Mini Sparkle Motion https://github.com/adafruit/Adafruit-Mini-Sparkle-Motion-PCB

Hardware Configuration

nothing

How is Esptool Run

macOS terminal, or esptool-js in chrome

Full Esptool Command Line that Was Run

esptool.py chip_id

Esptool Output

esptool.py v4.8.1
Found 4 serial ports
Serial port /dev/cu.usbmodem59720877071
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP32
Chip is ESP32-U4WDH (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: ec:c9:ff:8a:53:cc
Uploading stub...

A fatal error occurred: Failed to write to target RAM (result was 01070000: Operation timed out)

More Information

Works fine on windows 11 laptop using same versions of esptool and esptool-js.
Works reading data but not writing on macOS with --no-stub flag to esptool.py

Please see here for further information (log files attached):
espressif/esptool-js#182

Other Steps to Reproduce

No response

I Have Read the Troubleshooting Guide

• I confirm I have read the troubleshooting guide.

[tyeth]

I'm actually getting write errors even with no-stub using esptool.py on macOS. I did successfully do a couple of simple read tests earlier in the day, including reading the entire flash to a file, but hadn't tried writing.

tyeth@MacBookPro wippersnapper.sparklemotionmini_esp32.littlefs.1.0.0-beta.95-6-gb72640a4 2 % esptool.py --no-stub write_flash 0x0 wippersnapper.sparklemotionmini_esp32.littlefs.1.0.0-beta.95-6-gb72640a4.combined.bin
esptool.py v4.8.1
Found 4 serial ports
Serial port /dev/cu.usbmodem59720879281
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP32
Chip is ESP32-U4WDH (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 30:c9:22:7a:46:28
Attaching flash from eFuses' SPI pads configuration(CLK:6, Q:17, D:8, HD:11, CS:16)...
Configuring flash size...
WARNING: In case of failure, please set a specific --flash_size.
Flash will be erased from 0x00000000 to 0x00162fff...
Erasing flash...
Took 6.39s to erase flash block
Writing at 0x00000000... (0 %)
A fatal error occurred: Failed to write to target Flash after seq 0 (result was 01050000: Requested resource not found)

[radimkarnis]

Hello @tyeth,
thanks for the report.

I've seen similar cases in the past (MacOS with 01070000: Operation timed out error, working elsewhere). This usually happens with a non-standard USB-to-UART bridge.

I looked at the PCB you are using and cannot identify the bridge. Judging from the port name (/dev/cu.usbmodem59720879281), this is something extra. All of the classic bridges (cp2102, ch340, ...) enumerate as /dev/cu.usbserialXXXX.

This issue is usually caused by delays in the UART communication, which can be a result of faulty drivers or the USB-to-UART bridge.

See this similar issue: #280 (comment)

A possibility is to use a configuration file and increase the timeouts used by esptool (I'd start with the mem_end_rom_timeout timeout and then the other ones if that doesn't help).

I tried to get my hands on similar faulty HW combination, but had no "luck" - never been able to reproduce this on my MacOS.

Please try to do this and let me know if that helped.

Thanks!

[tyeth]

Curious why it says resource not found.
It's an Intel Mac running Sequoia 15.3 beta 24D5034f, and I can send you one of my two boards (from UK to anywhere), or probably request to get one sent out (then you contact support - sent from Adafruit/USA). Or happy to do a remote video session if you like.

I've gone to the WCH site and installed the CH343DS1 related driver for mac, but not certain it's using the installed version rather than it's preferred bundled version (as the instructions suggest a /dev/tty.wchXXXXX device rather than tty.usbmodemXXX - but it's from 2022).

Attached trace of running esptool.py --trace --before no_reset --after no_reset --no-stub --chip esp32 --port /dev/tty.usbmodem59720877071 --baud 115200 write_flash 0x0 Downloads/wippersnapper.sparklemotionmini-esp32.1.0.0-beta.96-prod.bin --flash_size detect with the 1second set for mem_end_rom_timeout.

esptool_write_log_20250124_1342.txt

If you want to suggest some inflated config values to test as worst case, but I'm going off of the defaults here which all seem generous (ignoring sync and mem_end which I set at 1 and 2 respectively) and far less than the time between erase end and write failure
https://docs.espressif.com/projects/esptool/en/latest/esp32/esptool/configuration-file.html#options

Also happy to run other commands, but saw nothing in dmesg

I might try updating the OS in the mean time as there is a newer beta update, so let me know soon if you'd rather I didn't.

[tyeth]

Tried x10 for everything for kicks, still same situation, it immediately reports the resource not found like a driver issue after finishing the erase and beginning the write.

I used:

timeout=30.0
chip_erase_timeout=1200.0
max_timeout=2400.0
sync_timeout=1.0
md5_timeout_per_mb=80.0
erase_region_timeout_per_mb=300.0
erase_write_timeout_per_mb=400.0
mem_end_rom_timeout=2.0
serial_write_timeout=100.0
connect_attempts=70.0
write_block_attempts=30.0
reset_delay=0.5
open_port_attempts=10.0

with esptool.py --before no_reset --after no_reset --no-stub --chip esp32 --port /dev/tty.usbmodem59720877071 --baud 115200 write_flash 0x0 Downloads/wippersnapper.sparklemotionmini-esp32.1.0.0-beta.96-prod.bin --flash_size detect

[radimkarnis]

Tried x10 for everything for kicks, still same situation

Well, in that case increasing timeouts is not the way to go. Thanks for trying!

Curious why it says resource not found.

I have looked into the ROM code for the 01050000: Requested resource not found error. It appears as a possible error code in a few of the flash chip-related operations, but not in the serial communication-related commands. Please notice the WARNING: In case of failure, please set a specific --flash_size. message and try setting a specific flash size (can be read with the flash_id command).

can send you one of my two boards (from UK to anywhere)

No need, thanks! We will try to buy one of the devkits and reproduce the issue here.

[tyeth]

Thanks Radim, I did try with setting flash size argument, but same resource not found error

…

On Mon, 27 Jan 2025, 13:21 Radim Karniš, ***@***.***> wrote: Tried x10 for everything for kicks, still same situation Well, in that case increasing timeouts is not the way to go. Thanks for trying! Curious why it says resource not found. I have looked into the ROM code for the 01050000: Requested resource not found error. It appears as a possible error code in a few of the flash chip-related operations, but not in the serial communication-related commands. Please notice the WARNING: In case of failure, please set a specific --flash_size. message and try setting a specific flash size (can be read with the flash_id command). can send you one of my two boards (from UK to anywhere) No need, thanks! We will try to buy one of the devkits and reproduce the issue here. — Reply to this email directly, view it on GitHub <#1058 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTBZ4ZYG66WZQ7BM5WEQWT2MYXHFAVCNFSM6AAAAABVXVQ6EKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJVG42DSNZWGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tyeth]

Some of our staff have been unable to recreate the issue on various M1 mac's at various OS versions, when diagnosing a user with the same issue:
" tried to recreate this on a mac laptop and mac desktop (both m1). One was running macOS 12 and another was running macOS 15.1.1. I tried erasing flash, loading wled and the factory reset multiple times but I couldn’t get either one to throw the guru meditation error using our esptool" (Our tool = esptool-js / https://github.com/adafruit/Adafruit_WebSerial_ESPTool )

And the user reported issue:
https://forums.adafruit.com/viewtopic.php?t=216202

The user in the forum does have an M1 mac though, and I have an intel mac, so it must be possible to affect both.
We're running different OS versions (15.1.1 user M1 vs Intel Mac Sequoia 15.3 beta 25D5034f). No problems with Windows OS reported.

[tyeth]

@radimkarnis forget about this one. Driver issue as half expected.

The process for installing the CH341SER_MAC.zip / CH34XSER_MAC.zip / CH34xVCPDriver has one step that is a little hidden / easily missed.

When installing the WCH Serial driver for mac, there is a pop up explaining an unsafe extension is being installed, but the default button of OK doesn't finish the installation, instead click System Settings button to be taken to the Driver Extensions and enable the WCH Driver.

Alternatively the user must enable the driver extension manually, they need to goto System Settings -> General -> Login Items and Extensions -> Driver Extensions -> Enable WCH Driver extension, like in this video:
https://youtu.be/jzwnEFTLxIw

[radimkarnis]

I am "glad" that this did turn out to be a driver issue in the end. I was scratching my head with this one.

I will consider adding a Note message pointing the users to a possible driver issue if the 0107 error happens on MacOS.

Thanks for your investigation!