Skip to content
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

Possible ESP32 hanging WiFi scan issue #1939

Open
rujorgensen opened this issue Oct 1, 2020 · 6 comments
Open

Possible ESP32 hanging WiFi scan issue #1939

rujorgensen opened this issue Oct 1, 2020 · 6 comments
Labels

Comments

@rujorgensen
Copy link

@rujorgensen rujorgensen commented Oct 1, 2020

I've been having this issue (no need to read) with a "hanging" scan, meaning it never terminates.

I've been poking around the source, and was puzzled about something (I cannot directly relate this to my issue though):

  1. Only one scan can be handled at a time.
  2. The callback handler is assigned (== blocked) at line 894
  3. If I'm not mistaking, the scan is started at line 944
  4. The callback handler is released at line 369 when the scan is "culminated"
  5. Between assigning the callback handler (2) (and with that, blocking all later scans), and starting the scan (3), there are three return statements which would cause the scan to never be started at all (and thus, never free'ing the callback handler (4) allowing later scans)

Forgive me if I've missed something, embedded programming can be hard to keep an overview of for me 😬.

@MaBecker MaBecker added the ESP32 label Oct 1, 2020
@gfwilliams gfwilliams changed the title Possible ESP32 hanging scan issue Possible ESP32 hanging WiFi scan issue Oct 2, 2020
@gfwilliams
Copy link
Member

@gfwilliams gfwilliams commented Oct 2, 2020

Hi,

Are you saying that the WARNING: Scan stop failed always happens before subsequent scans fail? So it's possible that whatever causes that error isn't clearing state properly?

It's not entirely unexpected that this happens even after calling reset() because the reset() will reset the JS interpreter's state, but not the WiFi.

I'm afraid I'm too busy to look into this properly today.

For now a hack would be to detect the scan failing (a setTimeout to see if you got a result in 30s?) and then do a hard reboot with E.reboot()

@rujorgensen
Copy link
Author

@rujorgensen rujorgensen commented Oct 2, 2020

Are you saying that the WARNING: Scan stop failed always happens before subsequent scans fail? So it's possible that whatever causes that error isn't clearing state properly?

Yes, but ... it turns out this warning is related to BLE, so it's probably unrelated to my issue. I only get this after flashing, but not when resetting the hardware (either by cutting power, or using ESP32.reboot()).

It's not entirely unexpected that this happens even after calling reset() because the reset() will reset the JS interpreter's state, but not the WiFi.

That explains it 👍. I might add that everything seems to work fine after using ESP32.reboot() too.

For now a hack would be to detect the scan failing (a setTimeout to see if you got a result in 30s?) and then do a hard reboot with E.reboot()

Nice tip, but I feel that in my particular application, a hard reboot would be a bit drastic (the scan is kind of a secondary function only) 🙂.

I think I see the problem a little more clearly now. This seems to be directly related to flashing the device, and that comforts me a little, because I would probably not see the issue "in the field".

  • I still think my original observation about a potential issue is still valid though.

  • I think the state of the WiFi should be cleared after a flash (not doing so is probably also what causes the BLE issue above), because having to jump through hoops to simulate a "fresh", "in the field", device makes it very awkward to do development 😊.

@gfwilliams
Copy link
Member

@gfwilliams gfwilliams commented Oct 2, 2020

Thanks - yes, what you're saying about the callback seems totally valid, and like a complete mess.

I think the state of the WiFi should be cleared after a flash

Yes and no :) definitely g_jsScanCallback should be freed and cleared on the "kill" event handler, as should other stuff like that.

However WiFi itself shouldn't drop out on reset() as quite a few people seem to connect in via telnet to develop...

@rujorgensen
Copy link
Author

@rujorgensen rujorgensen commented Oct 2, 2020

definitely g_jsScanCallback should be freed and cleared on the "kill" event handler, as should other stuff like that.

Great, so leaving the issue open then 🙂?

However WiFi itself shouldn't drop out on reset() as quite a few people seem to connect in via telnet to develop...

Oh, sure--I don't have an overview of which resources are block/unblocked like g_jsScanCallback at all, but returning stuff like that to their initial state was what I meant 😊.

@gfwilliams
Copy link
Member

@gfwilliams gfwilliams commented Oct 5, 2020

so leaving the issue open then?

Yes, totally!

@MaBecker MaBecker mentioned this issue Oct 9, 2020
16 of 28 tasks complete
@MaBecker
Copy link
Contributor

@MaBecker MaBecker commented Oct 12, 2020

what you're saying about the callback seems totally valid, and like a complete mess.

Well, there is Wifi for ESP8266, for ESP32 and for Espruino boards using a ESP01 as Wifi module and they are all slightly different to the "ESP01 as Wifi implementation" until some starts working on it and align the callbacks.

Nice to have would be callback(err, .....)

At the moment I only see some user reporting their findings and less than a hand full of contributors for unsupported boards.

To be honest, if you need this functionality for your project, jump in and contribute.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants