ESP32: Wifi peripheral configuration is not reset before/after a soft reset or light/deep sleep.
After a soft reset, micropython restarts with the wifi peripheral configuration continuing as set prior to the reset.
This may be regarded as a feature by some (eg. continued connection to wifi Access Point) after reset, however, it
- requires additional unexpected and undocumented protection code in startup scripts
- eg.
sta.connect(ssid, pwd)will raise an exception after a soft reset if already connected().
- eg.
- difficult to diagnose errors can arise in circumstances where the peripheral is left in a bad state or a state unexpected by the users or the micropython software after reset.
I have made the mistake of chasing apparent bugs in my apps (or while developing PR #6515) only for them to resolve after a hard reset. I have also dealt with a number of users reporting issues which have turned out to be due to the wifi peripheral being in a bad state and not being re-initialised after a soft reset. I suspect this may also be contributing to user frustration with apparent lack of reproducibility or reliability.
I propose to prepare a PR which:
- calls esp_wifi_stop() and esp_wifi_deinit() before soft reset
- also before deepsleep/lightsleep() as required according to W-fi Bluetoth Sleep Modes
An alternative may be to call esp_wifi_deinit() on bootup before esp_wifi_init().
I am aware that some may rely on the current (undocumented) behaviour, though I believe that for predictability and reproducibility it is much more desirable to allways start micropython with the peripheral in a known state.
mpremote: on ESPxxx all mpremote commands are followed by a hard reboot
according to @jimmo mpremote should be able to resume a repl session on a connected mcu without a reboot by using the following command pattern:
mpremote connect exec "start_something()"
mpremote connect resume exec "continue_here()"
where the resume is the important part.
see Discord discussion
however when I try this :
- I see that any variables set in the the first
mpremotecommands are lost - I see that the esp32 performs a soft reset after exiting the
raw REPL
(observed through logic analyzer)
So even though the 2nd mpremote command does not force a reset, by that time a soft reboot has already occurred.
I also see a soft reset after:
- exiting the repl
- eval "42"
- exec "print(42)"
Actual result on windows :
C:\develop\usb>mpremote exec "foo=bar=42;print(foo)"
42
C:\develop\usb>mpremote resume exec "print(bar)"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'bar' isn't defined
Expected
the MCU not to reset between two mpremote commands similar to the behavour on linux
$ mpr exec "foo=bar=42; print(foo)"
42
$ mpr exec "print(bar)"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'bar' isn't defined
$ mpr exec "foo=bar=42; print(foo)"
42
$ mpr resume exec "print(bar)"
42
results as seen by a logic analyzer hooked up to the RX/TX pins of the esp32
\x01\x03
>>>
>>>
>>>
>>>
raw REPL; CTRL-B to exit
\x02OKx05A\x01foo=bar=43;print(foo)\x04
MPY: soft reboot
raw REPL; CTRL-B to exit
>R\x01\x80\0\x01\x0443
\x04\x04>ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:4540
ho 0 tail 12 room 4
load:0x40078000,len:12448
load:0x40080400,len:4124
entry 0x40080680
MicroPython v1.19.1 on 2022-06-18; 4MB/OTA module with ESP32
Type "help()" for more information.
>>>
>>>
>>>
>>>
>>>
raw REPL; CTRL-B to exit
\x02R\x01\x80\0\x01\x04\x04Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'foo' isn't defined
\x04>ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:4540
ho 0 tail 12 room 4
load:0x40078000,len:12448
load:0x40080400,len:4124
entry 0x40080680
MicroPython v1.19.1 on 2022-06-18; 4MB/OTA module with ESP32
Type "help()" for more information.
>>>
other observations
- same behavior is observed with multiple firmware versions, and on different boards
- esp8266 devices do NOT soft-reset in the same way ( note: all my esp8266 devices use a different serialport driver)
Versions
- mpremote : 0.4.0
- pyserial: 3.5
- Python 3.9.13
- Version: 1.72.2 (user setup)
- OS: Windows_NT x64 10.0.22621
- Micropython - v1.19.1
- MCU - all esp32
- serial port driver esp32 : Silicon Laboratories Inc. 11.1.0.53
- serial port driver esp8266 : wch.cn - No version or other details
> mpremote devs
COM9 01665F52 10c4:ea60 Silicon Labs None # esp32
COM11 0001 10c4:ea60 Silicon Labs None # esp32
COM20 00000000A 0403:6001 FTDI None # UART debug
COM21 1a86:7523 wch.cn None # ESP8266
firmwares
- mpremote connect com9 get-info
{'ver': 'v1.19.1', 'build': '', 'platform': 'esp32', 'port': 'esp32', 'machine': 'ESP32 module (spiram) with ESP32', 'release': '1.19.1', 'nodename': 'esp32', 'name': 'micropython', 'family': 'micropython', 'sysname': 'esp32', 'version': '1.19.1'} - mpremote connect com11 get-info
{'ver': 'v1.19.1', 'build': '', 'platform': 'esp32', 'port': 'esp32', 'machine': '4MB/OTA module with ESP32', 'release': '1.19.1', 'nodename': 'esp32', 'name': 'micropython', 'family': 'micropython', 'sysname': 'esp32', 'version': '1.19.1'} - mpremote connect com21 get-info
{'ver': 'v1.19.1', 'build': '', 'platform': 'esp8266', 'port': 'esp8266', 'machine': 'ESP module (1M) with ESP8266', 'release': '1.19.1', 'nodename': 'esp8266', 'name': 'micropython', 'family': 'micropython', 'sysname': 'esp8266', 'version': '1.19.1'}
oldest firmware tested with same behavior:
- mpremote connect com9 get-info
{'ver': 'v1.10', 'build': '', 'platform': 'esp32', 'port': 'esp32', 'machine': 'ESP32 module with ESP32', 'release': '1.10.0', 'nodename': 'esp32', 'name': 'micropython', 'family': 'micropython', 'sysname': 'esp32', 'version': '1.10.0'}