Add unix tight reset #387
Add unix tight reset #387
Conversation
Adds a reset approach for *nix called UnixTight reset by Espressif to avoid timing issues with USB-serial connections on Linux and macOS. See espressif/esptool#712 for details.
Add a #[cfg(unix)] I forgot (so it actually builds on windows).
Fixed formatting.
|
I was able to do some further testing on Linux (Arch Linux) and successfully flashed the following devkits:
|
|
Just did some further testing on macOS 13.3.1 and successfully flashed the following devkits:
|
Keep comments consistent.
|
Using a WT32-SC01 Plus on Debian 11.7 this patch improves things (board goes from "can't connect" to "works with caveats") As can been seen above, I have to press Ctrl-C to abort the first attempt (if I don't, the program just waits forever - I'm guessing that the default delay is shorter than a few minutes) no further attempts are tried. The official esptool works |
Fix #[cfg(unix)] (and windows build).
Clean experimental code
| self.serial.write_data_terminal_ready(false)?; | ||
| self.serial.write_request_to_send(false)?; | ||
|
|
||
| self.serial.write_data_terminal_ready(true)?; | ||
| self.serial.write_request_to_send(false)?; | ||
| self.serial.write_data_terminal_ready(true)?; | ||
| self.serial.write_request_to_send(true)?; |
There was a problem hiding this comment.
Where does this come from? esptool doesn't do this. (?)
Also, since in unix_tight_reset we have the IO0/EN comments, it would be good to have them here too
There was a problem hiding this comment.
This is the only difference I can discern between this branch and the branch I have trying to solve this issue. If these 4 lines are all it takes to get my branch working that would be great, but I would like to be certain this does not have detrimental effects on other OSs.
There was a problem hiding this comment.
This bit of code essentially turns classic reset into unix tight reset. This seems to work because of the way the retrying is working currently:
Here, we should be retrying the UNIX reset for X attempts, and then moving on to the classic mode.
|
FWIW, the reset issue seems to be specific to Apple Silicon Macs. I'm not able to get this to run successfully on my M1 MacBook Pro (MacBookPro18,2 MK233LL/A), nor does I'm trying to probe the signals on my scope, but the board doesn't break them out easily for my aged eyes and fingers. |
|
Tried this on my M1 mac and no luck. Has anyone managed to flash device with ARM Macs? Are there any workarounds? |
I have an M1 Mac Mini that I use all the time without issue. |
Which module and serial driver (if not the built-in Apple driver with Ventura) are you using? Having the same issue with M1 MacBook Pro and various ESP boards (Teyleten Robot, ESP-WROOM-32 and ESP32-C3-DevKitM-1; LilyGo T5 EPaper displays using ESP32). I can't think of a reason why Mini vs laptop should make a difference here, though it's certainly a possibility... |
|
Apparently the issue on my system isn't the reset. It's failing on the first I've instrumented espflash to print out the commands being sent, and everything is identical. It's just the response to the Then, on Linux, I get: But from the Mac, I get: |
|
The current fix worked for me. |
|
There's definitely something going on lower level, my hunch is with the specific UART IC and driver being used, or possibly that and transistors and pullups. I'm back to looking at the reset timing, and spent a good part of the weekend staring at oscilloscope traces between (good) Linux flashing and (bad) M1 Mac flashing sequences, unable to discern a meaningful difference on the EN, GPIO0, TX, and RX lines. JTAG flashing does work, but many of my devices lack a USB-JTAG-attached port. |
|
Chiming in in support of this PR: was able to flash a esp32-wroom-32d on an M1 macbook pro using this fork, installed using the command below cargo install --git https://github.com/AVee/espflash --branch add_unix_tight_reset cargo-espflash espflash |
|
My issue appears to be very specific to a certain board with a peculiar rev of a UART + M1 Mac. <sigh> Specifically, the Teyleten Robot ESP32-C3-DevKitM-1 board, but with the WCH343 UART (not pictured in the Amazon links). |
|
Can anyone affected by this issue check if #487 fixes the issue? |
|
Closing in favour of #487 |
This adds the 'UnixTight' reset to flash method that Espressif added to EspTool to fix espressif/esptool#712. It takes some things from #344 but I tried to minimize the code impact a bit more. If more ways of resetting show up in the future the approach of actually creating an explicit ResetStrategy trait might still turn out to be better.
The flow is slightly different from what EspTool does, as this first tries UnixTight and Classic resets with the normal delay and then retries both with the longer delay. I think that should be fine as the same things are tried, just in a different order.
I've tested this on Linux and Windows, but not on macOS. It would be nice if someone could test that.