Pico hangs, is non responsive after machine.soft_reset()

[jimkoke]

First - this is a Pico 2W, so I don't know that the RP2040 applies, but its all that I found for the Pico.

My application is configuring the WiFi, I prompt the user to select an SSID and provide the password, I then write the pair to a config file and reboot (machine.soft_reset())- expecting the Pico to restart, read the config file and attach to the WiFi. However, the Pico just seems to "brick", no response, no AP wifi as if to get another ssd/pwd, and Thonny does not see it. I have unplugged the Pico for a long time (10+ minutes) and back in, no difference. I've had to nuke it, reinstall MP (latest version), and then it seems to be happy again. It would seem my method (get new said/pw and reboot into that) is viable, any insights to what is happening?

Anticipating .... I use Thonny because it is simple and after hopping from project to project in my career, I found myself using simple (vi) as that is always available.

[Josverl]

I would suggest using machine.reset() to not only reset the python VM, but also reset the hardware.

If that does not help, please share (a link to) your minimal code sample.

[jimkoke]

I don't have a link to the minimal code sample, so here it is (below). When main.py uses "soft_reset" and I run main.py, I see "MPY: soft reboot" then the message from boot.py. When main.py uses "reset" and I run main.py, I see the message from boot.py then this:

(I deleted my minimal code example because it was stupid, I'll come up with another)

[scruss]

are you sure you've written (and flushed, and closed) the config file before the board is reset?

[jimkoke]

If you are referring to the minimal code, there is no config file.

The way I deal with files in python is:

with open(file, <mode>) as f:
    <operations>

I rely on the "with" construct to call the close() method, and I presume the close() method will handle flushing.

[scruss]

It should, but a flush will do no harm.

I lost my fascination with finding the "perfect tool" decades ago on projects with fixed budgets.

In this case, experienced people like Robert are telling you that Thonny can be part of the problem. Thonny is great for simple development, but for times you're resetting the device under software control, it will do the wrong thing.

[robert-hh]

Please try to replicate the situation without using Thonny. Use simple terminal emulators like mpremote or Putty or screen instead. Thonny is not good in fail situations.
Another question: do you have the Pico's file system mounted as a drive at the PC? That may lead to file corruption, if the board writes to the file system as well.

[jimkoke]

I do not have the Pico mounted, I'm using a Mac, BTW.

I'm not well versed in the various ways of communicating with a Pico during development. I found Thonny it "works", so I use it. My focus is on the end product; I lost my fascination with finding the "perfect tool" decades ago on projects with fixed budgets. The key point for me is how after the Pico gets "bricked", cycling power on the Pico does not produce the USB device in /dev, regardless of Thonny running. I could try this with VCS.

[jimkoke]

Another interesting data point ... I added another py file that is just:

something.py

import machine
print("something.py will now soft_reset()")
machine.soft_reset()
print("Something - soft_reset did not work")

boot.py

print("This is boot.py")

main.py

print("This is main.py")

When I run that with Thonny, the Pico does a soft reset, runs boot.py, but does not run main.py:

MPY: soft reboot
This is boot.py
something.py will now soft_reset()
�MPY: soft reboot
This is boot.py

main.py was not called, I suspect because it was not at the root of the calling tree.

Moving on, I wrote a more elaborate main.py that adds a line to config if it exists and does its own machine.soft_reset() if config had less than 10 lines (watchdog). If config did not exist, it is created and I import the something.py file which immediately does a soft_reset() which does the reset as expected.

It seems that machine.soft_reset() results in main.py running only when main.py had been at the root of the calling tree. This does not explain (to me at least) why my minimal code sample (above) "ruins" the Pico to the point of having to nuke it. I'm not trying machine.reset() as I'm tired of nuking...

[robert-hh]

At which point do you run something? Manually or by adding import something to main.py or boot.py?

[robert-hh]

And b.t.w.: Thonny operates the REPL in raw mode. In that case, main.py will not run. That is one reason why I asked you to test without Thonny. While it is convenient for simple situations, Thonny is good at bug hiding when things fail.

[robert-hh]

I grabbed a Pico 2W to simulate your simple test set-up. In normal mode, boot.py and main.py are called, in raw mode only boot.py. The example something.py always reboots the board as it should.
Calling machine.reset() will close the USB port, causing the connection to be closed.