ESP32-S default upload speed in Arduino IDE is too high, resulting in errors #8320
Comments
|
Can another user please verify this? If so, we can adjust the default upload speed |
|
@me-no-dev For development I use PlatformIO. Whatever baud rate they set always works. Of course that's also a faster computer. I've seen other users report issues with programming. I've recommended 460800 baud to them, but haven't heard back if that solved their issue. I feel like the default baud rate for programming may have changed somewhere around 2.0.6-2.0.7? |
SuGlider
added
IDE: Arduino IDE
|
@me-no-dev -I don't see 460800 upload speed option in the Arduino IDE Menu. I maybe add a PR to add the 460800 upload speed option and set it as default... Let me know. |
|
I see that 460800 is available in MacOS and Linux only. Not for Windows. |
|
I am also stuck in same issue while uploading sketch to ESP32 Lilygo display-S3, tried everything did not work, also checked every upload speed. There is no upload speed 460800 in windows i think |
This may be a different issue. In Arduino IDE please consider using the In the Some reference: |
|
Funny enough I can confirm this issue. Probably some layout is causing problems, even though baudrate in USB context does not mean anything. We could probably add 460800 to the menu for Windows. It's not there, because Windows did not support it. |
I will try these solutions hope it works, Thanks for your quick response. |
|
I had the same problem on macOS and lowering the upload speed to 460800 solved the problem. |
VojtechBartoska
added
Status: To be implemented
Ok, assigning to you @me-no-dev |
|
Hello! Any updates about this? I am running into the same corruption issues on an esp32cam, but running esptool directly with the 115200 baud does not have an issue! |
|
I do confirm issue. Spend few hiurs looking for reason of: It was enough to low down UploadSpeed! |
|
Same issue with me, MacOS Sonoma 14.1.1, Apple Silicon M1, uploading to two different ESP32 boards at 921600 fails, but 460800 works. Stumped me for a long time! |
|
I see 460800 as an option in Win11 on USB to FTDI chip. I've been using 460800 as the baud parameter to esptool.py for some time on an older Win10 computer. No issues. I recommend that as the default. I just verified that computer also shows 460800 as a valid baud rate for the FTDI adapter. For the physical COM1 port, it has max baud rates of 115200 and 128000. |
@richardloxley Hi, do you know how to change the upload speed in Arduino IDE for Mac? I am facing a similar issue, but I am not sure how to change the upload speed from IDE. It seems that the menu bar on Windows is missing on Mac. |
Got it. The menu bar is on top of the screen 😂. |
|
Is it doable to fix this for 3.0.0 @me-no-dev? |
|
@VojtechBartoska The fix is done with #9277 or do you mean an other issue? |
|
This was supposed to be closed by merging the fix #9277. So I am closing it now. |
github-project-automation
bot
moved this from In Review
to Done
in Arduino ESP32 Core Project Roadmap
|
I had the same problem. as below: |
|
Commenting on closed tickets may not be productive, but in case anyone else lands here via search, the above "fix" is a little misguided. This isn't unique to S or any other Espressif model; it's a bummer at the crossroads of the MacOS driver and the USB/Serial bridge used. The MacOS drivers for the CH34x serial drivers almost work. They break at high speeds in an intermittent way, so your upload may work one time and fail the next or break when it grows to five sectors instead of four or something. This problem affects ALL the boards with the WCH CH34x family of chips, which includes the CH9102. (WCH part numbers are zany.) A good illustrated tutorial to installing the fixed drivers can be found at https://learn.adafruit.com/how-to-install-drivers-for-wch-usb-to-serial-chips-ch9102f-ch9102/mac-driver-installation Yes, it's disturbing to install a driver in Chinese with mixed labeling for a chip you may not have and that you have to override the security "Are you sure?" prompts TWICE to install, but that's just where we are. When you have this installed, use the /dev/cu.wchWHATEVER dev nodes instead of /dev/cu.WHATEVER and you can run the speeds up to about 2Mbps if you wish, though anything above about 1.5Mbps isn't measurably different. You'll never get that throughput sustained when writing to flash, but that's no longer a serial issue. Obviously, this fix is not applicable to the parts with CDC via native USB/Serial bridge on silicon. /dev/cu.usbmodemFOO drivers use the CDC/ACM drivers and are not affected by this issue. The underlying issue of the native drivers sucking has been with us for many MacOS releases. I just checked Sequoia 15.1 on an M1 and it's still broken—just enough that, say, monitor works and upload of short programs works but uploads of big programs fall over. 10.15 on a 2012 iMac is identically broken, so it's a bug with tenure. I suspect the native driver is not recognizing a stall condition on the bulk (interrupt?) pipe and isn't properly clearing and restarting it when a FIFO is full, but my days of debugging such things via protocol analyzers are over. :-) We no longer get Darwin source to verify that or implement a fix. Fortunately, WCH has provided us with a good driver, but they've not paid Apple the $99/year to get the driver signed. |
|
@robertlipe Was a Windows user from the begining and switched to Mac when the M1 appeared. Maybe Mac Users are used to "it just works". Since I was used to nothing works without installing a driver (with Windows), this was not a big thing that for this Serial chip a driver needs to be installed to get it working with all features. |
|
UNIX dude that went Mac years ago, also seeking that "it just works" experience. This case is a bit frustrating, and that's pretty rare. (I was also a pro serial driver dev, so maybe I just react to it more.) as the drivers in MacOS almost work. They work well enough that a lot of people don't immediately suspect that they have to install a working driver. (Witness the number of smart people on this thread that slightly misdiagnosed it.) If anything, the cure might be more self-evident if the factory driver didn't exist. The native MacOS driver for the CH340/Ch9102 almost works,and that's the stinky thing. It just drops data at really high speeds when you have a lot of it, even on transmit, which is the easy case for a serial driver. So for firmware upload, a small program may be fine four times out of five, but as the program grows, it may start failing on every upload, but only a minute or two into the upload. An ESP32 firmware update above a certain size is almost guaranteed to break in a way that the protocol won't recover from. I've been through this with dozens of posters. The cure is 100% to install the drivers from WCH. It's not unique to the ESP32-S. (I hve no ESP32-S boards in my life.) It's not unique to a specific board. Lots of boards use those CH340 chips and THEY are the problem. It's been broken long enough that someone should probably raise open a ticket with Apple to get it fixed. I know already it'll be hard to convince them that it's their problem when it requires XXMB of SDK + $10 of hardware involving another CPU and many megabytes of transfer at 480K+ to trigger. I'd really rather let this be between Espressif/WCH and Apple. Sigh. Espressif team, do you want to tackle this at the root? Maybe get the WCH team involved and let them license the working driver or take an update into the OS masters or something? |
|
@robertlipe There is still something fishy in espressif code. I am flashing every esp32x with 1.5M without any issues (with all USB serial converter chips out there). |
|
I do, too - but only if I use /dev/cu.wch.BLAH and not /dev/cu.BLAH.
So I grabbed the board that was beside me here in bed (don't judge!) which
doesn't have a CH.340, I can see it's under-achieving:
esptool.py --baud 1500000 --port /dev/cu.usbmodem1101 read_flash 0
0x1000000 junk
Read 16777216 bytes at 0x00000000 in 178.5 seconds (752.1 kbit/s)...
Hmm. Flash should be fast than that.
esptool.py --baud 1500000 --port /dev/cu.usbmodem1101 dump_mem 0x40000000
0x1000000 junk
11264 bytes read... (0 %)
HAHAHAHA. You HAVE to be kidding. No, you're right. It's faster at 115200.
That's just broken. Like "they forgot to set the speed" kind of broken.
esptool.py --baud 230400 --port /dev/cu.usbmodem1101 dump_mem 0x40000000
0x100000 junk
is at least vaguely in the game. I'll be I know what they've done there,
though. There's a special ioctl you have to all on MacOS to get speeds
above 230K. Let's take this one offline because I'll bet that you and I
could figure this out. Send me your favorite test case.
I'm this same address @ gmail.
…On Sat, Dec 28, 2024 at 11:07 AM Jason2866 ***@***.***> wrote:
@robertlipe <https://github.com/robertlipe> There is still something
fishy in espressif code. I am flashing every esp32x with 1.5M without any
issues (with all USB serial converter chips out there).
BUT I never managed to *read* any esp32x faster than 115200. Weird since
reading is way more "work" for the flash chip than writing.
—
Reply to this email directly, view it on GitHub
<#8320 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD3YQW4Y7YFZXN2YQSRL2H3LG7AVCNFSM6AAAAABUJIDDH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUGM4DEMJWG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
|
|
Correct. This is an S3 using the native serial port, not a UART.
When I'm next out of bed, I'll check.. Is that syntax enough? Is it esptool
we're fingering for the crime or is it required make the ESP write a test
pattern to the UART to see data loss?
Is it your theory that if we hooked two
https://github.com/espressif/esp-usb-bridge's in a null modem configuration
and send data in one and out the other that the receiving ESP would confirm
that it's received all the data but that the host will not receive what the
ESP sends to the host?
➜ which esptool.py ; file $(which esptool.py)
/opt/homebrew/bin/esptool.py
/opt/homebrew/bin/esptool.py: symbolic link to
../Cellar/esptool/4.8.1_1/bin/esptool.py
I haven't actually used the esp-bridge app, but if I choose to fall asleep
tomorrow with different hardware or otherwise leave this bed, I can perhaps
bring some with more serial ports, :-) but it seems we're involving more
hardware and more code. If suspecting driver issues, confirming it with cat
will be more satisfying than dumpster diving around
in /opt/homebrew/Cellar/esptool/4.8.1_1
I just know from experience that MacOS requires a different ioctl to set
bit rates beyond the POSIX speed of 230K, so if python is trying to call
'stty', for example, it's doomed, but that would present in a different way
than I think you're describing. I've had to teach several uploaders this (a
couple from STM and Bouffalo) this trick in recent years.
Should we be conscious that we're taking a closed ticket even further OT?
…On Sat, Dec 28, 2024 at 3:09 PM Jason2866 ***@***.***> wrote:
/dev/cu.usbmodem1101 is using the espressif inbuilt "USB modem" Here
reading works fast without using or "respecting" speed settings. It uses
whatever speed.
I am speaking from external USB Serial converter chips like the wch340.
Try to ready a bigger flash area with higher speed than 115200. It will end
in an error.
—
Reply to this email directly, view it on GitHub
<#8320 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD35VC7MWPRZS44M2WKD2H4HRFAVCNFSM6AAAAABUJIDDH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUGQ3TEMZYGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Agree littering this issue. We can chat in pioarduino Discord https://discord.gg/Nutz9crnZr |
Board
NodeMCU ESP32-S
Device Description
NodeMCU ESP32-S
Hardware Configuration
No
Version
latest master (checkout manually)
IDE Name
Arduino IDE
Operating System
macOS 13.4 Ventura
Flash frequency
??
PSRAM enabled
yes
Upload speed
921600
Description
When trying to upload to a NodeMCU ESP32-S on Mac M1, the default upload speed of 921,600 is too high resulting in errors like this:
Or this:
This can confuse new users (like me) who don't know which default settings they have to tweak in order to upload.
I tested this with two NodeMCU ESP32-S.
Setting the upload rate to a lower value (e.g. 460800) fixes the error.
To reproduce
Sketch
This happens with any script, e.g. the default Blink script.Debug Message
Sketch uses 235937 bytes (18%) of program storage space. Maximum is 1310720 bytes.
Global variables use 22056 bytes (6%) of dynamic memory, leaving 305624 bytes for local variables. Maximum is 327680 bytes.
esptool.py v4.5.1
Serial port /dev/cu.usbserial-4140
Connecting.....
Chip is ESP32-D0WD (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: a4:e5:7c:db:1c:2c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00005fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x00049fff...
Compressed 17520 bytes to 12170...
Writing at 0x00001000... (100 %)
Wrote 17520 bytes (12170 compressed) at 0x00001000 in 0.7 seconds (effective 213.8 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 146...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (146 compressed) at 0x00008000 in 0.1 seconds (effective 267.2 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.2 seconds (effective 400.8 kbit/s)...
Hash of data verified.
Compressed 236304 bytes to 129987...
Writing at 0x00010000... (12 %)
Writing at 0x0001e222... (25 %)
Writing at 0x0002421b... (37 %)
Writing at 0x000293fa... (50 %)
Writing at 0x0002ea8c... (62 %)
Writing at 0x00036fdb... (75 %)
Writing at 0x0003f0ee... (87 %)
Writing at 0x000446ea... (100 %)
Wrote 236304 bytes (129987 compressed) at 0x00010000 in 3.6 seconds (effective 527.0 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
The text was updated successfully, but these errors were encountered: