For the folks running Thonny

[kdschlosser]

Thonny and MicroPython do not play nice nice with each other with regards to resetting the ESP32. MicroPython has provided no mechanism to be able to gracefully shutdown any hardware that is in use from C code when soft resetting the ESP32. MicroPython's built in wrapper code for hardware gets shit down properly and that is because of function calls that are made from the core of MicroPython to shut down and clean up this things specifically. It is actually rather frustrating that there is no way to handle this properly.

The only way to get the hardware to get cleaned up properly is to perform a hard reset. Thonny only does a soft reset so we need to change the code in Thonny so it does a hard reset. There is yet another frustrating issue with this is USB-CDC. Instead of using the hardware USB CDC stack that is built into the any ESP32 that supports direct USB connections MicroPython authors have made the decision to use a software USB CDC stack instead. The problem there is they did not add the handling of the DTR and CTS signals which are what is used to perform a hard reset and boot mode selection... So that means the omnly way to get the ESP32's to hard reset is to actually close the serial connection to the ESP32. EVEN when doing that I am not 100% certain that the ESP32 will actually hard reset when connected using the USB CDC.

If you want to give it a run then here are the instructions. I have not tested this at all so whoever tries it please let me know if it works properly and what the errors are that come up.

Download the attached file and remove the .txt extension from the end of the filename and drop the file into thonny/plugins/micropython.

serial_connection.py.txt

Let me know if it works on ESP32's using USB CDC as well.

[gitcnd]

Yeah - the DTR and RTS handing on ESP32 is SNAFU. It's not possible to fix it for all boards unfortunately.

This is my command-line program which lets you access the repl over any serial, for any board:
https://github.com/gitcnd/mcu_serial

"Thonny" and "ampy" and "mpfshell" all use underlying python modules which have bugs in them (initialising the serial pulses pins), for which there is a workaround (initialize without telling it what port to use, then tell it the port afterwards).

I've done extensive work getting versions of all these things working, but not had any luck getting original folks to fix any bugs.

I've also added a pile of extra checking into them all (their "detection" of a working REPL was a total mess).

It doesn't help that there's multiple versions of everything (windows, linux, apple...).

Anyhow - if anyone wants all the fixes to get nicely working tools to talk to any esp32 chip, let me know. (yes - any esp32 - HUGE ask - since a mutually-exclusive set of them do (or do not) work depending on initial DTR/RTS settings.)

[gitcnd]

Here is my "ampy": https://github.com/gitcnd/ampy - not sure if it's the latest version or not of what I'm using locally. If it doesn't work for you, let me know.

I'm on WSL1 (Ubuntu) on windows.

export PORT=/dev/ttyS6
ampy --port $PORT put lvgl_test_2432S028R.py 
ampy --port $PORT ls -l -r 
>sent ^C^C^B
<got0:b''
>sent ^A^A
<got1:b'\r\n>>> \r\n>>> \r\n>>> \r\nLVGL (9.2.2) MicroPython (1.24.1) Binding compiled on 2025-02-03; Generic ESP32 module with SPIRAM with ESP32\r\nType "help()" for more information.\r\n>>> \r\n>>> \r\nraw REPL; CTRL-B to exit\r\n>'
>sent ^D (soft reset)
<got2:b'raw REPL; CTRL-B to exit\r\n>OK\r\nMPY: soft reboot\r\n'
<got3:b'raw REPL; CTRL-B to exit\r\n>OK\r\nMPY: soft reboot\r\n'
/.history.txt - 34 bytes
/boot.py - 139 bytes
/lib/sh.mpy - 13123 bytes
/lib/sh.txt - 14125 bytes
/lib/sh0.mpy - 4017 bytes
/lib/sh1.mpy - 3245 bytes
/lib/sh2.mpy - 4027 bytes
/lib/sh3.mpy - 2832 bytes
/lvgl_test_2432S028R.py - 2306 bytes
/settings.toml - 2119 bytes

[kdschlosser]

I too have modified ampy to it will work properly. I started work on writing a binding to a program called dookany which is a kernel mode driver for windows that exposes the API so it is able to be used to attach "virtual" storage devices as removeable storage devices. In Windows it shows up in File explorer as an actual drive and allow you to drag and drop, copy and paste, view properties, open files all of the typical things that you can do in File Manager. I ended up stopping because of the speed which was very slow due to the 115200 bits per second connection to an ESP32. The ability to alter the bitrate has since been added to the ESP32 line of MCU's and it might be time to start working on it again. It would be nice to be able to plug the ESP32 in and have the computer see and use it as a removable storage device.

I do not understand why there is a need to place the ESP32 into what is called "raw REPL" as this doesn't provide any additional abilities above standard REPL. and it's what causes some of the problems. Everything is able to be done passing the code to the standard REPL.

[gitcnd]

Yeah - it's a mess. I almost rewrote my own from scratch as well - looks like you got further than I did! I "gave up" after a pile of research on writing files to an esp32 as part of a device-driver setup revealed no possibility to avoid data corruption (besides resorting to "samba" techniques, which isn't going to work over serial).
I think, if a new attempt is done, some kind of web-browser framework makes most sense.
I got a console working ( https://chrisdrake.com/cfb/xterm.html?rts=0&dtr=0&flow=0 ) for attendees of a hardware meetup I ran last year https://chrisdrake.com/cfb/ ... so many almost-production-ready things ... so little time ...