dhcp_esp32c3 example fails to get an IP address when compiled in Release about esp-wifi HOT 16 CLOSED

I do have a branch which swaps out the allocator for esp-alloc, and I ran the dhcp_esp32c3 example on it multiple times today successfully. Might be worth giving a shot. I hope to get this merged soon (there are still some issues for the ESP32 in my branch, but ESP32-C3 has been working for me).

https://github.com/jessebraham/esp-wifi/tree/fixes/esp-alloc

from esp-wifi.

Thanks! There are a few more things worth to try

• try the different opt-levels for the release profile (0,1,2,3,"s","z") to see if that makes any difference
• comment out the wifi scanning (it's not needed for connecting)

Just to summarize what we know until know (and make sure I got everything correctly)

• it works in debug mode with your access-point
• it works with your phone's hot-spot also in release mode

Another thing that would be interesting but probably isn't convenient to try: Configuring different auth-methods on your AP - but I totally understand if you don't want to mess with your AP's configuration

from esp-wifi.

Thanks a lot for the effort

opt-level 0: After setting profile.release opt-level to 0 running cargo clean the esp fails to print the very first println!("{:?}", wifi_interface.get_status());. This is very strange since I would have expected opt-level 0 to be equivalent to the dev profile.

That is very surprising since it should be almost the same as dev profile. Very interesting

Really sorry for the inconvenience but the good thing is that we see similar behavior now in a PR ( #39 ) which changes some totally unrelated code - maybe finding out what is going on there might help here

from esp-wifi.

@jessebraham your branch works in dev for me but hangs at the same point in release. Are you running it in dev or release?

from esp-wifi.

Strange, I was running in release.

from esp-wifi.

Any other differences in the cargo command I'm running?
cargo +nightly run --example dhcp_esp32c3 --features=esp32c3,embedded-svc

from esp-wifi.

@jessebraham I re-ran it and it worked. I had a look through my bash history though and I didn't change anything between runs other then unplugging the esp32c3 and replugging it into USB. Not sure if that could have anything to do with it, hopefully it's not an intermittent issue.

from esp-wifi.

Sorry, my mistake - that run that worked was in dev, not release.

from esp-wifi.

That is very interesting since especially on ESP32-C3 things used to work quite smooth for us.

First thing that would be interesting: Which version of the Rust compiler are you using?

On my machine it looks like this:

❯ rustc --version --v
rustc 1.63.0-nightly (76761db59 2022-05-24)
binary: rustc
commit-hash: 76761db5919b6d2e178b26947ad9b4fcb0ff0e7c
commit-date: 2022-05-24
host: x86_64-pc-windows-msvc
release: 1.63.0-nightly
LLVM version: 14.0.4

Next there are a couple of things you can do to get more log output:

• activate the feature wifi_logs
• activate the feature dump_packets
• in the example there is a line log::set_max_level(log::LevelFilter::Info);, changing that to log::set_max_level(log::LevelFilter::Trace); will generate a huge log of every important function called

Comparing the outputs of the different logs in develop and release mode might hopefully reveal something.

And one more thing you could try: Connect to a different WiFi network (e.g. a WiFi hotspot on your smartphone).

Hope we can get this sorted out

from esp-wifi.

Already rustc is showing me an older version. Let me update rustup. Here's what I got for my rustc version:

> rustc --version --v
rustc 1.61.0 (fe5b13d68 2022-05-18)
binary: rustc
commit-hash: fe5b13d681f25ee6474be29d748c65adcd91f69e
commit-date: 2022-05-18
host: x86_64-unknown-linux-gnu
release: 1.61.0
LLVM version: 14.0.0

from esp-wifi.

Ok so updating rustup didn't change my results but then I tried using my phone's hotspot and it worked. So the issue is something specific to my Wifi Network.

Here's what the relevant wifi networks look like:

AccessPointInfo { ssid: "HOTSPOT", bssid: [xxx, xxx, x, xxx, xx, xxx], channel: 11, secondary_channel: None, signal_strength: 17, protocols: EnumSet(), auth_method: WPA2Personal }
AccessPointInfo { ssid: "HOME_WIFI", bssid: [xxx, xxx, xxx, xxx, xx, xxx], channel: 9, secondary_channel: Below, signal_strength: 33, protocols: EnumSet(), auth_method: WPAWPA2Personal }
AccessPointInfo { ssid: "HOME_WIFI", bssid: [xxx, xxx, xxx, xxx, xx, xx], channel: 9, secondary_channel: Below, signal_strength: 62, protocols: EnumSet(), auth_method: WPAWPA2Personal }

Two things stand out to me immediately about the network that doesn't work in release:

1. It shows up twice as 2 access points (which makes sense - it's a tp-link Deco mesh network with two router/repeater devices)
2. It's auth method appears to have the word WPA duplicated(?) for some reason: WPAWPA2Personal

from esp-wifi.

Trying again with wifi_logs, dump_packets and log level trace renders a Store/AMO access fault error in both dev and release and does not appear to get past wifi scanning in either:

https://gist.github.com/D1plo1d/c481b0aea3682814dcbeb4e23947ba9f

Edit: It's not obvious but there's both a dev and release log in that gist. Release log starts here: https://gist.github.com/D1plo1d/c481b0aea3682814dcbeb4e23947ba9f#file-release

from esp-wifi.

Thanks for testing! Those exceptions are really weird. Did you try that on Jesse's branch? If yes could you re-try it with esp-wifi main? I ask since it looks like the exception happens immediately after an alloc and the experimental branch replaces the way how memory is allocated

It doesn't make too much sense why it is only happening with full logs since the logs shouldn't allocate heap memory but worth a try anyways

from esp-wifi.

No problem! Yeah that was on Jesse's branch. I've switched back to esp-wifi's main branch now and it seems to never get further then scanning for Wifi (although notably it no longer errors):

https://gist.github.com/D1plo1d/2ae896ed17d1fc5580f2fb453244717c

from esp-wifi.

One more thing: Initially you wrote it gets until Start busy loop on main, right?
Do your AP show the device as connected at that point? What does the printed result for wifi_connect looks like?

from esp-wifi.

Just to summarize what we know until know (and make sure I got everything correctly)

Yeah, this is turning out to be a bit of a complicated one. That all looks correct.

Do your AP show the device as connected at that point?

No, the list of connected devices doesn't change when I run the esp-wifi example in --release.

Another thing that would be interesting but probably isn't convenient to try: Configuring different auth-methods on your AP - but I totally understand if you don't want to mess with your AP's configuration.

Yeah I can't easily do that atm - my housemates depend on this AP as well.

comment out the wifi scanning (it's not needed for connecting)

Commenting out wifi scanning resulted in release getting to wifi_connect returned and then not any further - although it's hard to tell for sure because the logs are getting garbled.

Eg. I found wifi_connect returned was output as: _connect e_recvreturned Ok retur(())

Perhaps there is a synchronization issues that causes logs from other sources to get mixed with the output of println! when I set the logging level to Trace?

I also tried switching the println! calls to log::info! but it didn't resolve the issue.

try the different opt-levels for the release profile (0,1,2,3,"s","z") to see if that makes any difference

• opt-level 0: After setting profile.release opt-level to 0 running cargo clean the esp fails to print the very first println!("{:?}", wifi_interface.get_status());. This is very strange since I would have expected opt-level 0 to be equivalent to the dev profile.
• opt-level 1, 2, "s", and "z": This stops at Start busy loop on main, same as it does with the default opt-level.

from esp-wifi.