Open frederictobiasc opened 2 months ago
I just tried this and it works fine for me. One of my ESP32-C3 dev-kits frequently reset because of BROWNOUT_RST but another worked fine.
What I did
cargo xtask run-example examples esp32c3 wifi_access_point
from the repo (commit 0363169084ac6c25ba40196a977f8cd789652880)esp-wifi
AP and get a shellping
❯ .\adb.exe shell
SDW:/ $ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=8.34 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=52.8 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=2.91 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=23.6 ms
64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=2.85 ms
64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=3.23 ms
64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=26.5 ms
64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=3.28 ms
64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=4.32 ms
64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=31.6 ms
64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=2.57 ms
64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=6.97 ms
64 bytes from 192.168.2.1: icmp_seq=13 ttl=64 time=2.83 ms
64 bytes from 192.168.2.1: icmp_seq=14 ttl=64 time=71.9 ms
64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=2.31 ms
64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=3.24 ms
64 bytes from 192.168.2.1: icmp_seq=17 ttl=64 time=4.30 ms
64 bytes from 192.168.2.1: icmp_seq=18 ttl=64 time=5.87 ms
64 bytes from 192.168.2.1: icmp_seq=19 ttl=64 time=5.12 ms
64 bytes from 192.168.2.1: icmp_seq=20 ttl=64 time=2.36 ms
64 bytes from 192.168.2.1: icmp_seq=21 ttl=64 time=15.3 ms
64 bytes from 192.168.2.1: icmp_seq=22 ttl=64 time=95.8 ms
64 bytes from 192.168.2.1: icmp_seq=23 ttl=64 time=3.09 ms
64 bytes from 192.168.2.1: icmp_seq=24 ttl=64 time=4.75 ms
64 bytes from 192.168.2.1: icmp_seq=25 ttl=64 time=22.6 ms
64 bytes from 192.168.2.1: icmp_seq=26 ttl=64 time=18.3 ms
64 bytes from 192.168.2.1: icmp_seq=27 ttl=64 time=17.1 ms
64 bytes from 192.168.2.1: icmp_seq=28 ttl=64 time=17.1 ms
64 bytes from 192.168.2.1: icmp_seq=29 ttl=64 time=4.60 ms
64 bytes from 192.168.2.1: icmp_seq=30 ttl=64 time=7.98 ms
64 bytes from 192.168.2.1: icmp_seq=31 ttl=64 time=5.45 ms
64 bytes from 192.168.2.1: icmp_seq=32 ttl=64 time=3.68 ms
64 bytes from 192.168.2.1: icmp_seq=33 ttl=64 time=108 ms
64 bytes from 192.168.2.1: icmp_seq=34 ttl=64 time=59.2 ms
64 bytes from 192.168.2.1: icmp_seq=35 ttl=64 time=15.4 ms
64 bytes from 192.168.2.1: icmp_seq=36 ttl=64 time=12.9 ms
64 bytes from 192.168.2.1: icmp_seq=37 ttl=64 time=3.28 ms
64 bytes from 192.168.2.1: icmp_seq=38 ttl=64 time=4.97 ms
64 bytes from 192.168.2.1: icmp_seq=39 ttl=64 time=10.4 ms
64 bytes from 192.168.2.1: icmp_seq=40 ttl=64 time=21.6 ms
64 bytes from 192.168.2.1: icmp_seq=41 ttl=64 time=6.49 ms
64 bytes from 192.168.2.1: icmp_seq=42 ttl=64 time=2.67 ms
64 bytes from 192.168.2.1: icmp_seq=43 ttl=64 time=17.4 ms
64 bytes from 192.168.2.1: icmp_seq=44 ttl=64 time=103 ms
64 bytes from 192.168.2.1: icmp_seq=45 ttl=64 time=40.6 ms
64 bytes from 192.168.2.1: icmp_seq=46 ttl=64 time=14.8 ms
64 bytes from 192.168.2.1: icmp_seq=47 ttl=64 time=17.7 ms
64 bytes from 192.168.2.1: icmp_seq=48 ttl=64 time=16.8 ms
64 bytes from 192.168.2.1: icmp_seq=49 ttl=64 time=3.94 ms
64 bytes from 192.168.2.1: icmp_seq=50 ttl=64 time=2.92 ms
64 bytes from 192.168.2.1: icmp_seq=51 ttl=64 time=28.1 ms
64 bytes from 192.168.2.1: icmp_seq=52 ttl=64 time=72.2 ms
64 bytes from 192.168.2.1: icmp_seq=53 ttl=64 time=2.98 ms
64 bytes from 192.168.2.1: icmp_seq=54 ttl=64 time=49.5 ms
64 bytes from 192.168.2.1: icmp_seq=55 ttl=64 time=3.33 ms
64 bytes from 192.168.2.1: icmp_seq=56 ttl=64 time=3.38 ms
64 bytes from 192.168.2.1: icmp_seq=57 ttl=64 time=4.26 ms
64 bytes from 192.168.2.1: icmp_seq=58 ttl=64 time=12.2 ms
64 bytes from 192.168.2.1: icmp_seq=59 ttl=64 time=3.31 ms
64 bytes from 192.168.2.1: icmp_seq=60 ttl=64 time=48.7 ms
64 bytes from 192.168.2.1: icmp_seq=62 ttl=64 time=49.9 ms
64 bytes from 192.168.2.1: icmp_seq=63 ttl=64 time=34.3 ms
64 bytes from 192.168.2.1: icmp_seq=64 ttl=64 time=119 ms
64 bytes from 192.168.2.1: icmp_seq=65 ttl=64 time=3.47 ms
64 bytes from 192.168.2.1: icmp_seq=66 ttl=64 time=51.4 ms
64 bytes from 192.168.2.1: icmp_seq=67 ttl=64 time=17.4 ms
64 bytes from 192.168.2.1: icmp_seq=68 ttl=64 time=15.6 ms
64 bytes from 192.168.2.1: icmp_seq=69 ttl=64 time=15.6 ms
64 bytes from 192.168.2.1: icmp_seq=70 ttl=64 time=4.45 ms
64 bytes from 192.168.2.1: icmp_seq=71 ttl=64 time=2.91 ms
64 bytes from 192.168.2.1: icmp_seq=72 ttl=64 time=2.62 ms
64 bytes from 192.168.2.1: icmp_seq=73 ttl=64 time=35.7 ms
64 bytes from 192.168.2.1: icmp_seq=74 ttl=64 time=75.4 ms
64 bytes from 192.168.2.1: icmp_seq=75 ttl=64 time=15.2 ms
64 bytes from 192.168.2.1: icmp_seq=76 ttl=64 time=13.4 ms
64 bytes from 192.168.2.1: icmp_seq=77 ttl=64 time=34.5 ms
64 bytes from 192.168.2.1: icmp_seq=78 ttl=64 time=4.32 ms
64 bytes from 192.168.2.1: icmp_seq=79 ttl=64 time=3.22 ms
64 bytes from 192.168.2.1: icmp_seq=80 ttl=64 time=75.8 ms
64 bytes from 192.168.2.1: icmp_seq=81 ttl=64 time=3.42 ms
64 bytes from 192.168.2.1: icmp_seq=82 ttl=64 time=4.33 ms
64 bytes from 192.168.2.1: icmp_seq=83 ttl=64 time=89.6 ms
64 bytes from 192.168.2.1: icmp_seq=84 ttl=64 time=3.98 ms
Maybe you see frequent resets on the ESP32-C3 like I do for one of my boards?
Closing for now - feel free to reopen with updated information
Hi @bjoernQ and thanks for checking.
I have four ESP32-C3-DevKitC-02 v1.1 at hand and tested all of them. Two of them were never used before. I made sure to use the exact same commit as you did (https://github.com/esp-rs/esp-hal/commit/0363169084ac6c25ba40196a977f8cd789652880).
I used the following stations for testing:
I confirm that the Android Phone seems to be able to establish a reliable connection. I tested this with ADB shell like you did. All other devices disassociated because of Beacon Loss and show a similar ping report like the one in my report above. There is no improvement when I provide the devkits with 3.3v directly from my lab PSU.
Using ESP-IDFs softAP example works well on all my four devkits.
Could you please check with another station apart from your android phone?
I tried again with my Windows box.
❯ netsh wlan show interfaces
Es ist 1 Schnittstelle auf dem System vorhanden:
Name : WLAN
Beschreibung : Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW)
GUID : be67aad6-52c7-45b8-94a9-b2d0338e53f0
Physische Adresse : 40:1c:83:10:a4:2d
Benutzeroberflächentyp : Primär
Status : Verbunden
SSID : esp-wifi
BSSID : 36:b4:72:4c:44:18
Netzwerktyp : Infrastruktur
Funktyp : 802.11n
Authentifizierung : Offen
Verschlüsselung : Keine
Verbindungsmodus : Profil
Band : 2,4 GHz
Kanal : 1
Empfangsrate (MBit/s) : 6
Übertragungsrate (MBit/s) : 6
Signal : 99%
Profil : esp-wifi
The ping result looks a bit worse compared to my Android phone
Antwort von 192.168.2.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=463ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=532ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.2.100: Zielhost nicht erreichbar.
Antwort von 192.168.2.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=370ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=438ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=3ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=366ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.2.100: Zielhost nicht erreichbar.
Antwort von 192.168.2.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=34ms TTL=64
Zeitüberschreitung der Anforderung.
Antwort von 192.168.2.1: Bytes=32 Zeit=696ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=75ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=867ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=3ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=930ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=3ms TTL=64
Zeitüberschreitung der Anforderung.
Antwort von 192.168.2.1: Bytes=32 Zeit=397ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=472ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=734ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=4ms TTL=64
Zeitüberschreitung der Anforderung.
Antwort von 192.168.2.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=835ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=12ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=966ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=4ms TTL=64
There are especially some bad peaks
Maybe worth to try tweaking some settings: https://github.com/esp-rs/esp-hal/blob/main/esp-wifi/tuning.md
(Sorry the output is from a German Windows installation but I guess it's not too hard to guess what the messages say)
Hi @bjoernQ,
I investigated the beacon error and there seems to be something seriously wrong with esp32-c3's Wi-Fi setup via esp-hal
.
I did two wireshark captures on the same devkit hardware with two different firmwares flashed:
Flash command: idf.py -p /dev/ttyUSB0 flash monitor
esp-hal/examples/wifi_access_point
Flash command: cargo xtask run-example esp-hal esp32c3 esp_wifi_access_point
The MAC address used as transmitter/source address by the ESP differs: | example | MAC |
---|---|---|
ESP-IDF softAP | 7c:df:a1:af:4f:75 | |
esp-rs wifi_access_point | 7e:df:a1:af:4f:74 | |
reported by espflash & esptool.py | 7c:df:a1:af:4f:74 |
The softAP example works flawlessly with every station I tried. The capture shows beacon frames at a 10 per second rate. This corresponds to the typical interval of 100 TU's.
On the other hand, the capture of esp-rs
wifi_access_point
example shows that only a single beacon frame is generated at the startup. This leads to the disassociation, because loss of beacons is interpreted as a signal loss.
Maybe there is some timer/interrupt misconfigured?
To capture beacon frames, the Wi-Fi adapter needs to be put into monitoring mode. I did this on my Arch notebook like follows:
Replace wlp3s0 with your interface's name.
systemctl stop NetworkManager
iwconfig wlp3s0 mode monitor
ip link set wlp3s0 up
Then start Wireshark and start capturing on wlp3s0
.
Launching the example with feature wifi-logs
enabled leads to the following endlessly repeating message:
INFO - The previous beacon was not Tx done
The previous beacon was not Tx done
is an interesting observation. Reopening the issue
Ok that's interesting. I see the same logs for ESP32-C3 but not e.g. on ESP32-C6.
Hi @bjoernQ. I just tried this with the v0.20.1 release as well as latest master (d71434adfb7573c267d4d41a4304a2c556d59231). The issue is still there, unfortunately. I also ran into a new issue: https://github.com/esp-rs/esp-hal/issues/2111
Is there anything I can do to help to get this fixed?
Hi!
I'm trying to get a project with an ESP32-C3 as Wi-Fi AP running. However, even the examples lead to the following error:
When I associate a station with the network of the esp32-c3, the station goes in a reconnection loop. After a few seconds, the driver signals missed beacons and finally disassociates. Then, it reconnects, and the loop starts again.
I also tried different esp32c3's as well as different Wi-Fi stations, to make sure it's not a hardware fault.
Logs:
Please note: This doesn't seem to affect ESP32. I can only reproduce it on ESP32-C3.
How to reproduce
I checked against the latest master (967c478846a501bfac2f54a3eade158586aed7d3 as well as v0.18.0)
cargo xtask run-example esp-hal esp32c3 esp_wifi_access_point