Uploads to Moddable Zero often fail under Windows 10

[wdimmit]

Uploading code (in this case the "drag" example) to the Moddable Zero fails more than 50% of the time.
This is under Windows 10 x64.

Two examples follow:

[phoddie]

Not our code. ;) Try turning the baud rate down in make.esp.mk. It defaults to 921600 on Windows, which esptool considers safe (no warning at the speed, though the same speed on Mac does give a warning). Good rates to try: 460800, 230400, and 115200. That last one should be reliable, if slow.

[phoddie]

FWIW - the maximum baud rate appears to be a function of the computer, USB driver, and perhaps USB cable. We held a workshop recently using only Windows computers and there were no upload failures at 921600.

[wdimmit]

Thanks. I'll try some more options. Do the docs that calls out that config option somewhere?

Also, sometimes the transfer fails before it actually starts (the second screenshot). I'm sometimes seeing the following error printed to terminal a few seconds after a failure or after terminating xsbug. Could xsbug be holding the port open?

C:\Users\retro\src\moddable\tools\serial2xsbug\win\serial2xsbug.c(489): The I/O operation has been aborted because of either a thread exit or an application request.

[wdimmit]

Sorry, need to revise that description. The message about serial2xsbug.c appears after disconnecting the usb cable. As a general rule, does the device need to be disconnected and reconnected between flashes?

[phoddie]

We've not seen a failure on Windows because of the baud rate. If that turns out to be your problem, how to change the baud rate should be documented.

There is no need need to disconnect before flashing.

[wdimmit]

Alright - USB cable #3 is much better than the first two I tried - I'm back up at 921600. For users who haven't used an ESP in a few years, it might be worth calling out that the situation is sensitive to cable selection.

With the good cable, I now see the serial2xsbug.c error immediately after closing xsbug if I happen to terminate the batch script first. With my first cable, the message was not appearing until I disconnected the device. Retrying the upload before the message appears seems to always fail.

I apparently had a Goldilocks cable to get exactly this problem, but wanted to describe it here in case someone in the future asks about it.

[phoddie]

Failures were due to a cable that couldn't handle high speed data. Closing as that is the primary issue here. The batch behavior is being addressed separately.