New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESP32: Hangs when reopening WiFi connection #4269

Closed
nickzoic opened this Issue Oct 25, 2018 · 2 comments

Comments

Projects
None yet
3 participants
@nickzoic
Copy link
Contributor

nickzoic commented Oct 25, 2018

This is a copy of micropython/micropython-esp32#167 reported by @peterhinch to bring it across to the main repo.

Summary: when waiting on network events, such as in a loop like:

while not s.isconnected(): pass

As far as I understand it, the network background tasks never get run, so the loop never ends. This isn't as intended.

As a workaround, if utime.sleep_ms(11) or machine.idle() is called, this yields the micropython task and allows other tasks to run. This shouldn't be left to the Python programmer though.

@dpgeorge

This comment has been minimized.

Copy link
Contributor

dpgeorge commented Dec 27, 2018

Thanks for copying this across from the old repo, and thanks @nickzoic for the following hint how to fix it:

We also haven't really answered the question of why it works on the first reset ... what changes?

So it works fine after a hard reset, but not after a soft reset. That really points to it being a problem with soft reset, in combination somehow with FreeRTOS scheduling. Since including a long sleep in the waiting works around the issue, this further points to an problem with soft reset and how idling works.

After some investigation I disabled threading and it fixed the problem. Then I just disabled the GIL and that also fixed the problem. Thus it's a problem with soft reset and the GIL, in combination with FreeRTOS scheduling.

In the end the fix is simply to release the GIL when deinitialising the uPy runtime, which is now done in fa50047 . This fix makes sense regardless of the issue here.

In summary: I think what was happening is that the main uPy task still had hold of the FreeRTOS mutex (corresponding to the GIL) upon soft reset and this put the uPy task on a special FreeRTOS scheduling queue (perhaps raising its priority) which prevented network events getting delivered to it after soft reset. There GIL mutex was reinitialised upon soft reset but this didn't help because FreeRTOS had no way to know that the old one was no longer used.

@dpgeorge dpgeorge closed this Dec 27, 2018

@mattytrentini

This comment has been minimized.

Copy link
Contributor

mattytrentini commented Dec 27, 2018

That's great news, thanks Damien! I'm sure @peterhinch will be happy too; this issue had been bothering him for a long time. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment