cpu/esp32: esp_wifi netdev driver #10762

gschorcht · 2019-01-13T17:13:53Z

Contribution description

Even though this netdev driver was already part of the initial PR for ESP32, it was in an experimental state and officially not supported.

This PR fixes a lot of problems and makes the driver operational. ESP32 can now be used with infrastructure mode WiFi. If the router of the LAN is IPv6 capable and provides a global routing prefix, EPS32 gets global connectivity.

The PR contains the following changes in detail:

Fix of a serious memory leak. The buffer given by the WiFi driver has to be freed explicitly. Otherwise the esp_wifi_netdev stops working after some seconds.
Fix of frame size handling. Although the MTU is 1500, it used uint8_t for transmitted and received frames before.
Automatic reconnect after disconnect. If WiFi is disconnected, e.g., because of timeout for beacon frame, it is tried to reconnect automatically.
Static WiFi configuration. The WiFi configuration has to be static to avoid memory access problems when WiFi AP is reconnected.
Registration of RX callback. RX callback function should be registered when WiFi has been connected to AP successfully and should be unregistered when WiFi disconnects from AP.
Call of wifi_connect in event handler. Before function wifi_connect is executed, starting the WiFi driver should have been finished. This is indicated by the WiFi driver by sending event SYSTEM_EVENT_STA_START. Function wifi_connect is moved therefore to the event handler for SYSTEM_EVENT_STA_START.
Fix of handling NETOPT_IS_WIRED. Although esp_wifi is a wireless interface, it returned true instead of false.
Fix of handling NETOPT_LINK_CONNECTED. esp_wifi was simply returning the connection state instead of filling the referenced value.
Fix of event types in event handler.
Improvement of some debug messages.

Testing procedure

Compile and flash example/gnrc_networking to at least one ESP32 node using your AP configuration, e.g.,

CFLAGS='-DESP_WIFI_SSID=\"<your SSID>\" -DESP_WIFI_PASS=\"your passphrase\"' USEMODULE="esp_wifi" make BOARD=esp32-wroom-32 -C examples/gnrc_networking flash

Once the application is flashed connect the ESP32 node with any terminal programm with a default baudrate of 115.200 bps. You should be able to observe an output as follows:

 I (1885949) [      wifi]: mode : sta (30:ae:a4:41:60:f8)
 I (1885950) [     event]: system_event_sta_start_handle_default
 I (1885958) [main_trampoline]: main(): This is RIOT! (Version: 2018.10-RC1-947...)
 RIOT network stack example application
 All up, running the shell now
 >
 I (1888371) [      wifi]: n:8 0, o:1 0, ap:255 255, sta:8 0, prof:1
 I (1890036) [      wifi]: state: init -> auth (b0)
 I (1890045) [      wifi]: state: auth -> assoc (0)
 I (1890121) [      wifi]: state: assoc -> run (10)
 I (1890143) [      wifi]: connected with <your SSID>, channel 8
 I (1890144) [      wifi]: pm start, type: 1
 I (1890144) [     event]: system_event_sta_connected_handle_default

Ping any host in your LAN.
If your router provides a global routing prefix, check with ifconfig that the prefix is set.
Stress testing from LAN with sudo ping6 fe80::<IID> -Ieth0 -s1392 -i 0.0001 should be stable over hours.

Issues/PRs references

This PR depends on PR #10766

gschorcht · 2019-01-13T17:16:53Z

@TimoRoth Might be interesting for you 😉

TimoRoth · 2019-01-14T10:00:09Z

Indeed. I wonder, would this work in parallel with ESP-NOW?

gschorcht · 2019-01-14T10:15:33Z

@TimoRoth Theoretically yes, since ESP-NOW is using Vendor Action Frames which are management frames that can be transmitted/received in parallel to an association a station has to an AP.

However, the implementation does not support it at the moment. The reason is that each module has its own WiFi initialization. While esp_wifi initializes the WiFi interface in Station mode, esp-now has to operate in in SoftAP+Station mode. So, one prerequisite will be to find a common initialization. You will already find an according comment int esp_now_setup.

Trying esp_wif in parallel to esp_now is the next item on my todo list. At the moment, it is a bit difficult to work on different drivers and merge them together since the dependencies increase and PRs are pending long time.

If it is possible to use esp_wifi and esp_now in parallel, you would have two netifs so that one ESP node could act as a border router without having an Ethernet interface.

gschorcht · 2019-01-14T10:18:23Z

@TimoRoth BTW, I have a working esp_wifi for ESP8266 under test here.

gschorcht · 2019-01-14T23:36:01Z

@TimoRoth Good news, I had success with a modified version of your border router that is working with esp_wifi at outer interface and esp_now at inner interface. The only prerequisite is that ESP-NOW uses the same channel as the AP to which esp_wifi is associated. This can be configured by compile time parameter ESP_NOW_CHANNEL.

TimoRoth · 2019-01-15T12:21:39Z

We kind of gave up on esp8266 after the majority of our devices turned into unflashable bricks within weeks of experimenting with them, but having more feature support for them is definitely nice.

Being able to use a single ESP32 board as border router would definitely be amazing. I'm wondering a bit what the advantage of ESP-NOW would be though, as there does not seem to be a massively reduced power draw over a normal WiFi connection.

I'll give this all a test run soon!

gschorcht · 2019-01-15T15:36:44Z

@TimoRoth

I'm wondering a bit what the advantage of ESP-NOW would be though, as there does not seem to be a massively reduced power draw over a normal WiFi connection.

The advantage of using GNRC and RPL over ESP-NOW would be that you can span a mesh network without having access to the AP from all nodes.

cpu/esp32/esp-wifi/doc.txt

smlng

code wise this looks pretty much okay and ready to go, however we really need some testing on this one: @MrKevinWeiss and @MichelRottleuthner can you give it quick try, our working group AP should distribute an IPv6 ULA prefix (fd.. something) so you can use that for testing.

cpu/esp32/esp-wifi/doc.txt

cpu/esp32/esp-wifi/esp_wifi_netdev.c

cpu/esp32/include/cpu_conf.h

smlng · 2019-01-16T08:30:24Z

merge #10766 before this one

MrKevinWeiss · 2019-01-16T10:08:54Z

I can do some testing later in the week, pretty busy now...

gschorcht · 2019-01-16T16:15:12Z

@smlng Thank you for your review. Let's hope that we get merged it in short term.

MrKevinWeiss · 2019-01-16T16:49:37Z

@gschorcht are you trying to get this in the release?
@aabadie is this an issue?

gschorcht · 2019-01-16T16:55:13Z

@MrKevinWeiss

are you trying to get this in the release?

I'm not sure, even though it was there it was not supported officially til now. But it would be an enhancement if ESP32 could communicate using an infrastructure mode WiFi.

MrKevinWeiss · 2019-01-16T17:25:20Z

Either way I should be able to do some testing tomorrow morning and ask @jia200x to get the other PR in. I know lots of people are interested in this!

MrKevinWeiss · 2019-01-16T17:48:44Z

I was able to flash but every second or two I get
INFO # I (184295) [ event]: system_event_sta_disconnected_handle_default

Here is a bit more info:

Starting RIOT kernel on PRO cpu
2019-01-16 18:44:59,068 - INFO # I (428) [      wifi]: wifi driver task: 7, prio:30, stack:3584, core=0
2019-01-16 18:44:59,069 - INFO # I (433) [      wifi]: wifi firmware version: b987c01
2019-01-16 18:44:59,081 - INFO # I (437) [      wifi]: config NVS flash: disabled
2019-01-16 18:44:59,082 - INFO # I (442) [      wifi]: config nano formating: disabled
2019-01-16 18:44:59,084 - INFO # I (447) [system_api]: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
2019-01-16 18:44:59,099 - INFO # I (455) [system_api]: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
2019-01-16 18:44:59,100 - INFO # I (465) [      wifi]: Init dynamic tx buffer num: 48
2019-01-16 18:44:59,113 - INFO # I (469) [      wifi]: Init data frame dynamic rx buffer num: 64
2019-01-16 18:44:59,115 - INFO # I (474) [      wifi]: Init management frame dynamic rx buffer num: 64
2019-01-16 18:44:59,116 - INFO # I (481) [      wifi]: Init static rx buffer size: 1600
2019-01-16 18:44:59,129 - INFO # I (486) [      wifi]: Init static rx buffer num: 10
2019-01-16 18:44:59,130 - INFO # I (490) [      wifi]: Init dynamic rx buffer num: 64
2019-01-16 18:44:59,307 - INFO # I (675) [       phy]: phy_version: 3910, c0c45a3, May 21 2018, 18:07:06, 0, 2
2019-01-16 18:44:59,309 - INFO # I (678) [      wifi]: mode : sta (84:0d:8e:18:7e:30)
2019-01-16 18:44:59,321 - INFO # I (678) [     event]: system_event_sta_start_handle_default
2019-01-16 18:44:59,324 - INFO # I (685) [main_trampoline]: main(): This is RIOT! (Version: 2018.10-RC1-965-g4d1a0-test/10762)
2019-01-16 18:44:59,326 - INFO # RIOT network stack example application
2019-01-16 18:44:59,327 - INFO # All up, running the shell now
> 2019-01-16 18:45:01,722 - INFO #  I (3098) [     event]: system_event_sta_disconnected_handle_default

MrKevinWeiss · 2019-01-16T17:57:09Z

I am pretty sure it's me, I think the router is ipv4 only. I will try more tomorrow...

gschorcht · 2019-01-16T18:27:08Z

@MrKevinWeiss Thank you for trying 😄

Once the ESP32 can establish an association with the AP and can pass the authentication, it doesn't matter for link local IPv6 communication whether the router provides a global routing prefix or not. Since the IPv6 link local address fe80::<IID>/64 is generated from the MAC address, you should be able to ping another node in your LAN using its fe80::... address without router support.

From your log, I can see that your problem is definitely that your ESP32 node cannot establish the association to the AP. If it could establish an association but the authentication fails, your log would looks like as follows:

I (672) [     event]: system_event_sta_start_handle_default
I (679) [main_trampoline]: main(): This is RIOT! (Version: 2018.10-RC1-965-g4d1a0-esp32_esp_wifi_fix)
RIOT network stack example application
All up, running the shell now
> I (3090) [      wifi]: n:8 0, o:1 0, ap:255 255, sta:8 0, prof:1
I (5053) [      wifi]: state: init -> auth (b0)
I (5062) [      wifi]: state: auth -> assoc (0)
I (5136) [      wifi]: state: assoc -> run (10)
I (8191) [      wifi]: state: run -> auth (7c0)
I (8192) [      wifi]: n:8 0, o:8 0, ap:255 255, sta:8 0, prof:1
I (8192) [     event]: system_event_sta_disconnected_handle_default
I (8196) [      wifi]: state: auth -> init (0)
I (8201) [     event]: system_event_sta_disconnected_handle_default
I (10642) [      wifi]: n:8 0, o:8 0, ap:255 255, sta:8 0, prof:1
I (10643) [      wifi]: state: init -> auth (b0)
I (10650) [      wifi]: state: auth -> assoc (0)
I (10726) [      wifi]: state: assoc -> run (10)
I (13781) [      wifi]: state: run -> auth (7c0)
I (13782) [      wifi]: n:8 0, o:8 0, ap:255 255, sta:8 0, prof:1
I (13783) [     event]: system_event_sta_disconnected_handle_default
I (13787) [      wifi]: state: auth -> init (0)
I (13792) [     event]: system_event_sta_disconnected_handle_default
I (16211) [      wifi]: n:8 0, o:8 0, ap:255 255, sta:8 0, prof:1
I (16212) [      wifi]: state: init -> auth (b0)
...

Please double check your ESP_WIFI_SSID parameter setting.

The size of received and transmitted frames was stored in an uint8_t, which did not allow to process frames larger than 255 octets. However, WiFi has an MTU of 1500 octets.

esp_wifi returns false now.

esp_wifi was simply returning the connection state instead of filling the referenced value.

The WiFi configuration has to be static to avoid memory access problems when WiFi AP is reconnected.

The buffer given by the WiFi driver as parameter eb has to be freed explicitly. Otherwise the esp_wifi_netdev stops working after some seconds.

Before function wifi_connect is executed, starting the WiFi driver should have been finished. This is indicated by the WiFi driver by sending event SYSTEM_EVENT_STA_START. Function wifi_connect is moved therefore to the event handler for SYSTEM_EVENT_STA_START.

RX callback function should be register when WiFi has been connected to AP successfully and should be unregistered when WiFi disconnects from AP. Therefore, esp_wifi_internal_reg_rxcb is called now in event handler on event SYSTEM_EVENT_STA_CONNECTED. It is reset now on event SYSTEM_EVENT_STA_DISCONNECTED.

If WiFi is disconnected, e.g., because of timeout for beacon frame, it is tried to reconnect automatically.

To avoid further inconsistencies in documentation, README.md is not provided any longer

Fixes sporadic blocking of the wifi thread in esp_wifi_recv_cb function under heavy network load conditions when frames are coming in faster than they can be processed. Since esp_wifi_recv_cb function is not executed in interrupt context, the msg_send function used for ISR event can block when the message queue is full. With this change esp_wifi can be flooded with icmpv6 packets of maximum size without any problems over hours.

ESP-IDF heap handling has to be used for esp_wifi for stability reasons. Otherwise, heap is corrupted sporadically

gschorcht · 2019-01-17T16:40:00Z

@MrKevinWeiss @smlng Thanks for your support

gschorcht mentioned this pull request Jan 14, 2019

cpu/esp*: compile time configurations for ESP MCUs #10766

Merged

gschorcht mentioned this pull request Jan 14, 2019

gnrc_netif_t: A dynamic approach to ~~GNRC_NETIF_NUMOF~~. #9903

Closed

smlng requested a review from MrKevinWeiss January 16, 2019 08:03

smlng self-assigned this Jan 16, 2019

smlng reviewed Jan 16, 2019

View reviewed changes

cpu/esp32/esp-wifi/doc.txt Show resolved Hide resolved

smlng reviewed Jan 16, 2019

View reviewed changes

cpu/esp32/esp-wifi/doc.txt Outdated Show resolved Hide resolved

cpu/esp32/esp-wifi/esp_wifi_netdev.c Outdated Show resolved Hide resolved

cpu/esp32/esp-wifi/esp_wifi_netdev.c Outdated Show resolved Hide resolved

smlng suggested changes Jan 16, 2019

View reviewed changes

cpu/esp32/include/cpu_conf.h Outdated Show resolved Hide resolved

smlng added the State: waiting for other PR State: The PR requires another PR to be merged first label Jan 16, 2019

gschorcht mentioned this pull request Jan 16, 2019

cpu/esp32: modules crypto and hashes cannot be used together with module esp_wifi #10787

Closed

gschorcht added 18 commits January 17, 2019 17:10

cpu/esp32: fixes frame size handling in esp_wifi

078c47d

The size of received and transmitted frames was stored in an uint8_t, which did not allow to process frames larger than 255 octets. However, WiFi has an MTU of 1500 octets.

cpu/esp32: fixes NETOPT_IS_WIRED in esp_wifi

2c97377

esp_wifi returns false now.

cpu/esp32: fixes NETOPT_LINK_CONNECTED in esp_wifi

d24d73d

esp_wifi was simply returning the connection state instead of filling the referenced value.

cpu/esp32: use static WiFi config in esp_wifi

3ef35e1

The WiFi configuration has to be static to avoid memory access problems when WiFi AP is reconnected.

cpu/esp32: fixes serious memory leak in esp_wifi

8a1da21

The buffer given by the WiFi driver as parameter eb has to be freed explicitly. Otherwise the esp_wifi_netdev stops working after some seconds.

cpu/esp32: improved debug message in esp_wifi

f4cacc1

cpu/esp32: automatic reconnect after disconnect

c9684af

If WiFi is disconnected, e.g., because of timeout for beacon frame, it is tried to reconnect automatically.

cpu/esp32: fix of event types in esp_wifi

c0d4706

cpu/esp32: cleanup esp_wifi config parameters

e83a867

cpu/esp32: doc improvements in esp_wifi

1cf415a

cpu/esp32: redundant README.md removed

cb37288

To avoid further inconsistencies in documentation, README.md is not provided any longer

cpu/esp_common: doc fixes related to esp_wifi

7754a34

cpu/esp32: esp-wifi related doc changes

6caead7

cpu/esp32: fix stability issues of esp_wifi

6a99e86

ESP-IDF heap handling has to be used for esp_wifi for stability reasons. Otherwise, heap is corrupted sporadically

cpu/esp32: esp-wifi related doc changes

5bb05f0

gschorcht force-pushed the esp32_esp_wifi_fix branch from a22e0a5 to 5bb05f0 Compare January 17, 2019 16:11

smlng approved these changes Jan 17, 2019

View reviewed changes

smlng merged commit 495607d into RIOT-OS:master Jan 17, 2019

gschorcht deleted the esp32_esp_wifi_fix branch January 18, 2019 07:14

MichelRottleuthner mentioned this pull request Jan 21, 2019

esp8266: esp_wifi netdev driver #10792

Merged

aabadie added this to the Release 2019.01 milestone Jan 21, 2019

gschorcht mentioned this pull request Jan 25, 2019

cpu/esp8266: Fixes and improvements of esp_wifi netdev driver #10862

Merged

cpu/esp32: esp_wifi netdev driver #10762

cpu/esp32: esp_wifi netdev driver #10762

Uh oh!

Conversation

gschorcht commented Jan 13, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Contribution description

Testing procedure

Issues/PRs references

Uh oh!

gschorcht commented Jan 13, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TimoRoth commented Jan 14, 2019

Uh oh!

gschorcht commented Jan 14, 2019

Uh oh!

gschorcht commented Jan 14, 2019

Uh oh!

gschorcht commented Jan 14, 2019

Uh oh!

TimoRoth commented Jan 15, 2019

Uh oh!

gschorcht commented Jan 15, 2019

Uh oh!

Uh oh!

smlng left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

smlng commented Jan 16, 2019

Uh oh!

MrKevinWeiss commented Jan 16, 2019

Uh oh!

gschorcht commented Jan 16, 2019

Uh oh!

MrKevinWeiss commented Jan 16, 2019

Uh oh!

gschorcht commented Jan 16, 2019

Uh oh!

MrKevinWeiss commented Jan 16, 2019

Uh oh!

MrKevinWeiss commented Jan 16, 2019

Uh oh!

MrKevinWeiss commented Jan 16, 2019

Uh oh!

gschorcht commented Jan 16, 2019

Uh oh!

gschorcht commented Jan 17, 2019

Uh oh!

Uh oh!

gschorcht commented Jan 13, 2019 •

edited

Loading

gschorcht commented Jan 13, 2019 •

edited

Loading