On ULX3S, ESP32 cannot be reflashed after MicroPython installed

[jtmaston]

Hello!
Noticed a slight issue with the ULX3S, not sure if I should be reporting it to them or here.
With the passthru bit flashed, first flash of MicroPython works without issues (using both the version provided in the guide), as well as the most recent one. But after MicroPython is installed, it seems the chip cannot go back into bootloader mode (any subsequent calls to esptool.py just yield Invalid head of packet (0x08): Possible serial noise or corruption.). Only fix to this is to manually pull the chip into bootloader (I just short the boot0 and reset castellated pins to ground), wherein I can use esptool again.
Tested against Windows 10, Fedora Linux and MacOS (I lost my mind debugging it last night :) )
Tested on ULX3S v3.1.8, ESP32-WROVER
Tested using latest esptool.py, latest https://github.com/gojimmypi/ulx3s-examples/tree/master/passthru/Diamond (I recompiled just to be extra sure), also with https://github.com/emard/ulx3s-bin/tree/master/fpga/passthru (the 85f.bit)
Tested using micropython 1.14 and micropython-1.24.

Any ideas?

Thanks, Alex

[emard]

There is some issue/interplay between "passthru" bitstream and "esptool.py" esptool obviously evolves faster than passthru. Generally passthru tries to be "intelligent" and detect activity that resembles to those when esptool.py tries to upload bitstream and then drive GPIO0 and others to enter bootloader mode automatically but it doesn't always work reliable In the meantime load passthru in the flash, try few times, sometimes maybe holding or pressing BTN0 can improve chance to enter bootloader probably I should try to reproduce problem with latest esptool and get some better fix

…

On Fri, Jan 3, 2025 at 8:34 PM Alexandru Anastasiu ***@***.***> wrote: Hello! Noticed a slight issue with the ULX3S, not sure if I should be reporting it to them or here. With the passthru bit flashed, first flash of MicroPython works without issues (using both the version provided in the guide), as well as the most recent one. But after MicroPython is installed, it *seems* the chip cannot go back into bootloader mode (any subsequent calls to esptool.py just yield Invalid head of packet (0x08): Possible serial noise or corruption.). Only fix to this is to manually pull the chip into bootloader (I just short the boot0 and reset castellated pins to ground), wherein I can use esptool again. Tested against Windows 10, Fedora Linux and MacOS (I lost my mind debugging it last night :) ) Tested on ULX3S v3.1.8, ESP32-WROVER Tested using latest esptool.py, latest https://github.com/gojimmypi/ulx3s-examples/tree/master/passthru/Diamond (I recompiled just to be extra sure), also with https://github.com/emard/ulx3s-bin/tree/master/fpga/passthru (the 85f.bit) Tested using micropython 1.14 and micropython-1.24. Any ideas? Thanks, Alex — Reply to this email directly, view it on GitHub <#12>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4K2R56NJSPWBI4BFX7IUT2I3Q55AVCNFSM6AAAAABUSHJKBGVHI2DSMVQWIX3LMV43ASLTON2WKOZSG43DQMBXGI2DINI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[emard]

https://github.com/emard/ulx3s-bin/tree/master/fpga/dfu/85f-v317 try also this, dfu and passhthru shipped with latest boards probably you already had that but try again if it will be better than existing

…

On Fri, Jan 3, 2025 at 10:44 PM D EMARD ***@***.***> wrote: There is some issue/interplay between "passthru" bitstream and "esptool.py" esptool obviously evolves faster than passthru. Generally passthru tries to be "intelligent" and detect activity that resembles to those when esptool.py tries to upload bitstream and then drive GPIO0 and others to enter bootloader mode automatically but it doesn't always work reliable In the meantime load passthru in the flash, try few times, sometimes maybe holding or pressing BTN0 can improve chance to enter bootloader probably I should try to reproduce problem with latest esptool and get some better fix On Fri, Jan 3, 2025 at 8:34 PM Alexandru Anastasiu < ***@***.***> wrote: > Hello! > Noticed a slight issue with the ULX3S, not sure if I should be reporting > it to them or here. > With the passthru bit flashed, first flash of MicroPython works without > issues (using both the version provided in the guide), as well as the most > recent one. But after MicroPython is installed, it *seems* the chip > cannot go back into bootloader mode (any subsequent calls to esptool.py > just yield Invalid head of packet (0x08): Possible serial noise or > corruption.). Only fix to this is to manually pull the chip into > bootloader (I just short the boot0 and reset castellated pins to ground), > wherein I can use esptool again. > Tested against Windows 10, Fedora Linux and MacOS (I lost my mind > debugging it last night :) ) > Tested on ULX3S v3.1.8, ESP32-WROVER > Tested using latest esptool.py, latest > https://github.com/gojimmypi/ulx3s-examples/tree/master/passthru/Diamond > (I recompiled just to be extra sure), also with > https://github.com/emard/ulx3s-bin/tree/master/fpga/passthru (the > 85f.bit) > Tested using micropython 1.14 and micropython-1.24. > > Any ideas? > > Thanks, Alex > > — > Reply to this email directly, view it on GitHub > <#12>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AC4K2R56NJSPWBI4BFX7IUT2I3Q55AVCNFSM6AAAAABUSHJKBGVHI2DSMVQWIX3LMV43ASLTON2WKOZSG43DQMBXGI2DINI> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

[jtmaston]

Tested now with the new bitstream, same behavior. I'll strap a logic analyzer to it as soon as I can and I'll check if there are any differences between the generated signals and the ones from the original esp32-wrover devkit. I checked this very top-level today and it seemed like the RTS and CTS patterns weren't quite identical, so I expect the issue to be there. I'll return with my findings, thanks for the pointers!

[emard]

ah that is known issue, probably with small timing adjust maybe clocked registered for RTS/CTS to simulate this circuit with 2 bjt transistors doing simple logic usually found on esp32 boards. This logic circuit is not ideal and it probably generates small internal delay which may be required for esptool's

…

On Fri, Jan 3, 2025 at 10:55 PM Alexandru Anastasiu < ***@***.***> wrote: Tested now with the new bitstream, same behavior. I'll strap a logic analyzer to it as soon as I can and I'll check if there are any differences between the generated signals and the ones from the original esp32-wrover devkit. I checked this very top-level today and it seemed like the RTS and CTS patterns weren't quite identical, so I expect the issue to be there. I'll return with my findings, thanks for the pointers! — Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4K2RZNT3E3TTDJ55TZBDD2I4BM3AVCNFSM6AAAAABUSHJKBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRZHA3DMOBQGA> . You are receiving this because you commented.Message ID: ***@***.***>