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().
• 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.