Programming speed is terribly slow sometimes #44
Comments
|
My overall stats is that 2 out of 3 modules I used have this issue. |
|
I'm on ubuntu and I already turned off all the serial port plug&play crap - at least there're no syslog messages that something pokes into newly connected /dev/ttyUSB* device. |
Does reflashing |
|
Ok, test 1: |
|
Test 2: So, no, erasing flash or flashing in its entirety with a known good firmware doesn't help. |
|
I have a board with an FTDI USB-UART converter. Running under Arch Linux. I get: That seems about right for 115200 baud with overhead. |
|
Thanks. So, I diconnect builtin CH341 adapter via jumpers, and connect "known good" (used with a 1 of 3 modules with which I didn't have problems) PL2303 adapter: So, some USB-UART chips don't play well with esp8266 auto-bauding. I invited @projectgus to comment on this issues, as he contributed some patches to esptool to workaround ch340 issues. |
|
For completeness, going higher-baud (with the same PL2303 adapter): Btw, I surely tested 921600 before, possibly with another adapter and certainly with another module and it simply didn't work at all (wires are longer than minimal). |
|
@pfalcon which kernel version do you use? See http://lxr.free-electrons.com/source/drivers/usb/serial/ch341.c?v=3.18#L312 |
|
Will try to get that module built separately, otherwise running stock 3.13 of ubuntu 14.04. Thanks for the hint! |
|
Wow, it really can go up to large speeds (eg using 921600 baud): So I guess the bootloader autodetects the baud rate, and it's slow with the CH341 because that chipset for some reason decides to do 9600 baud. |
|
Had an "a-ha" moment when I saw @atalax's comment! Can you see if the commit 1a9b16f fixes the problem? I think the kernel doesn't send a new baud rate in set_termios if it thinks the baud rate hasn't changed from what was last set. Combined with the "default to 9600 on open()" bug means that the device can be set to 9600 but the kernel thinks it's still set at the higher speed, so doesn't change it. (I think when I "fixed" it before what I was doing was changing the baud rate a lot when testing, so it kept re-setting it correctly!) On my NodeMCU board (the rev 1 one) I seem to be able to reliably upload repeatedly at 230400, 460800 and mostly-reliably at similar speeds (400000, 500000). At the higher speeds it does seem to take a little longer (1-2 seconds) to sync correctly, maybe some tweaking of the timeouts for retries might help with that (try more times, more frequently?) but it's pretty good. |
|
(For completeness - I'm on Debian Jessie 3.16.7 so I definitely have the kernel bug mentioned above, too.) |
|
@projectgus: Right at time, I just finished unpacking ubuntu kernel tree to build it ;-). And yes, that was it! With your patch applied, and -b921600, I get consistent 200kbit/s, tried 3 times. Btw, I found another adapter and turn out it is also CH341! I used it with another esp8266 module which had this programming speed problems. So, for me the mystery is solved, thanks everyone for help! I'll let @themadinventor close it if he didn't receive similar mystery reports. @projectgus , so please submit a PR with this patch, btw, the link in your comment shows for me as |
|
Ok, for this to be ultimate benchmarking thread: The above "-b921600 / 200kbit/s" report was with external CH341. With board builtin, 921600 doesn't work, 460800 is highest, but with it it gets up to 290 kbit/s. |
|
And to add a bit of gossip, at another place (no access now) I had another USB-UART adapter, and I cannot be sure, but it likely was CP2102 (at least I had it in my collection). With it, ecp8266 didn't work well either - it booted, but as soon as intensive WiFi task was started, like scanning, it simply hanged. CP2102 is generally considered a good chip, but builtin 3.3 LDO might be a bit weak to power ESP8266 completely. (Again, information by memory, just to give some hints to a desperate googler). |
Based on information in espressif#44 espressif#44 (comment) Looks like if the kernels thinks the serial port is already set to <baudrate>, it won't set the baud rate in set_termios. Due to the pre-4.0 bug of always chosing 9600 baud on open, it's possible for the device to be set to 9600 but the kernel thinks it's set much faster. Not sure what I was thinking with the other fix in de97c54. It did seem a bit more reliable but possibly this was because when testing I kept changing the baud rate(!)
Based on information in espressif#44 espressif#44 (comment) Looks like if the kernels thinks the serial port is already set to <baudrate>, it won't set the baud rate in set_termios. Due to the pre-4.0 bug of always chosing 9600 baud on open, it's possible for the device to be set to 9600 but the kernel thinks it's set much faster. Not sure what I was thinking with the other fix in de97c54. It did seem a bit more reliable but possibly this was because when testing I kept changing the baud rate(!)
I've been bitten by this ever since 1st module I tried. For some modules, programming speed is very slow. Example below (using a patch to be submitted) shows that actual UART speed used by bootloader is likely 9600. The issues definitely depends on USB-serial adapter used. But what's most annoying is "persistent sticky" nature of the problem. For example, today I just unpacked a new board with CH341 adapter builtin, and first programming went fast, but all subsequent show speed as below. Google is pretty silent on this specific issue, so posting this, as this is more or less appropriate place for it hopefully. Please don't close this prematurely, let's collect stats and maybe find some pattern.
The text was updated successfully, but these errors were encountered: