You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
press and hold boot button on the board, start flash command, release boot button after flashing process starts
this is incomplete and holds the user hostage for an unnecessarily long amount of time.
A little backstory:
What is very likely the case here is that the ESP Rust Board - unlike the dev kit boards - lacks the required external components to put the mcu in DFU/bootloader mode (I see no dedicated chip to assert DTR and RTS).
The solution is to do this manually by
pressing and holding the boot button
pressing and releasing the reset button
releasing the boot button
(aka: you don't have to keep holding anything down for an extended amount of time while the build/flash commands are running)
furthermore (this is the "incomplete" part), unfortunately this means that cargo espflash --monitor will not ever work on these boards, since after flashing has completed you
4. have to reset the board once more to exit DFU mode and run the newly uploaded firmware
5. start espmonitor after said reset has been triggered.
use a hub.
I'm not aware of a situation where this would help. Did you maybe specifically mean "use a powered hub"? (although I'd say: if that helps your broken USB setup isn't "unpowered hub", it's "running outside of spec")
The text was updated successfully, but these errors were encountered:
"use a hub" is correct - there are a few reports that using hubs fix download/flashing issues, for example espressif/esptool#712 (comment)
ok, wow, so this seems to be a lot more cursed than I initially assumed, and one person even says a powered hub might interfere in a negative way (not sure I'm buying it in this instance, but eh, it's hardware, you never know).
Also, since the flashing process does work for tanks my initial assumption about missing DTR/RTS can't be quite right. My next theory was that timing issues might occur when using a very fast (USB-C/USB-3) USB setup, so I've connected the filthiest oldest USB2 hub I could find, but that didn't fix it for me either.
I'll close this issue and open a new one for clarified wording only.
in hello board it says
this is incomplete and holds the user hostage for an unnecessarily long amount of time.
A little backstory:
What is very likely the case here is that the ESP Rust Board - unlike the dev kit boards - lacks the required external components to put the mcu in DFU/bootloader mode (I see no dedicated chip to assert
DTR
andRTS
).The solution is to do this manually by
(aka: you don't have to keep holding anything down for an extended amount of time while the build/flash commands are running)
furthermore (this is the "incomplete" part), unfortunately this means that
cargo espflash --monitor
will not ever work on these boards, since after flashing has completed you4. have to reset the board once more to exit DFU mode and run the newly uploaded firmware
5. start
espmonitor
after said reset has been triggered.I'm not aware of a situation where this would help. Did you maybe specifically mean "use a powered hub"? (although I'd say: if that helps your broken USB setup isn't "unpowered hub", it's "running outside of spec")
The text was updated successfully, but these errors were encountered: