[ESP32 FG mode, stm32mp131 host, sdio mode] WiFi transmission rate

[renliangli]

Checklist

• [X] Checked the issue tracker for similar issues to ensure this is not a duplicate
• [X] Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• [X] Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

Expected behavior

WiFi transmission speed can reach the expected level

Actual behavior (suspected bug)

The actual transmission rate of WiFi downlink TCP is 1.18 Mbits/sec

raw transport throughput

Error logs or terminal output

root@sofar:/# dmesg | grep mmc
[    2.651651] mmci-pl18x 58007000.mmc: mmc0: PL180 manf 53 rev2 at 0x58007000 irq 45,0 (pio)
[    2.716092] mmc0: queuing unknown CIS tuple 0x01 [d9 01 ff] (3 bytes)
[    2.732790] mmc0: queuing unknown CIS tuple 0x1a [01 01 00 02 07] (5 bytes)
[    2.742361] mmc0: queuing unknown CIS tuple 0x1b [c1 41 30 30 ff ff ff ff] (8 bytes)
[    2.759702] mmc0: new SDIO card at address 0001
root@sofar:/#
root@sofar:/#
root@sofar:/# cat /sys/kernel/debug/mmc0/ios
clock:          25000000 Hz
actual clock:   25000000 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    0 (legacy)
signal voltage: 0 (3.30 V)
driver type:    0 (driver type B)

Steps to reproduce the behavior

1、insmod esp32_sdio.ko 2、iperf3 -s -i 1 -p 2222 3、iperf3 -c 192.168.2.144 -p 2222 -i 1 -t 30 -P 5 -R

Project release version

master

System architecture

other (details in Additional context)

Operating system

Linux

Operating system version

Linux version 5.15.67

Shell

sh

Additional context

No response

[mantriyogesh]

before running iperf, check issues in raw throughput and stabilise them.

Please send photo captured of your setup.

Also, please ensure that the porting guide is followed.

[renliangli]

raw transport throughput

We tested it on the PCB board, and SDIO has pull-up capabilities

[mantriyogesh]

1. Something is wrong yet. Also, did you test raw throughput in opposite direction?

2. Setup photo please? take close-up enough to possibly show the connections.

3. Is it ESP32 or ESp32-C6 for sdio slave? If ESP32, eFuse burning is done (check if required or not first)?

4. Pull-up values?

[renliangli]

Host --> ESP

ESP32

The pull-up resistance value is 4.7K

[renliangli]

Also, when will esp_hosted_ng release a version that supports SoftAP ?

[mantriyogesh]

4.7K is not acceptable value, btw. check the porting guide. Try to stick with the values we use. Minimal recommended is 10K, we use 51K. Expected on lines: CMD, DAT0,DAT1,DAT2,DAT3.

For ESP32-WROOM32, the efuse_burning is mandatory.

From above log, host tx seems good (still there is chance to be higher, but at is fair enough). however rx not.

Can you let us know what (blue and yellow) extra wires added beside esp32?

[mantriyogesh]

NG supports softAP already.

[renliangli]

efuse_burning has been done as required.

extra wires (blue and yellow) added beside esp32 is serial port firmware burning related cables.

[renliangli]

NG supports softAP already.

Does the latest NG code on the master branch already support SoftAp? When compiling ko, just add CONFIG_AP_SUPPORT， Is there anything that needs to be modified on the ESP side ？

[mantriyogesh]

Just add CONFIG_AP_SUPPORT = y at top.

Latest ng firmware to be used from master. It should already support softap.

[renliangli]

Just add CONFIG_AP_SUPPORT = y at top.

Latest ng firmware to be used from master. It should already support softap.

NG no longer supports softap+station ?

[mantriyogesh]

NG doesn't yet support softap+station. FG supports it.

[renliangli]

NG doesn't yet support softap+station. FG supports it.

How long does it take for NG support softap+station

[mantriyogesh]

It is not currently planned. so can't commit. If your use case is specific to station + softap, I would recommend using FG. it is supported there.

[mantriyogesh]

1. Did the raw throughput test both sides worked fine in your case @renliangli ?
2. Did you manage to change the pull-ups?

[renliangli]

1. Did the raw throughput test both sides worked fine in your case @renliangli ? yeah, The raw throughput test both sides worked fine, Above 20Mb.

how to enable wifi atuo reconnect after disconnected in FG station wifi mode ?

[mantriyogesh]

Short answer

Customise disconnected: Add hook of test_station_mode_connect() here

Long answer

1. Doc: Control path understanding
2. Doc: You would anyway arrive here through above link, just to point, Event Handler APIs
3. Doc: C demo Code: C demo -> test.c I think you are already past this.
4. Code: Event callbacks registered here
5. Code: Event callbacks hooks: https://github.com/espressif/esp-hosted/blob/250e29294a740a45dd853115a25b62f1b2cfc51b/esp_hosted_fg/host/linux/host_control/c_support/test_utils.c#L109-L147
6. Customise disconnected: Add hook of test_station_mode_connect() here

[!NOTE]

1. Try to use async event handlers when using in event handlers. We faced some issues in past for 'sync' handlers when used in event handlers. Except event handler hooks, in general, preference should always to 'sync' APIs.

   2. Diff between sync and async: In Async, you register response callback. In sync, you do not register response callback.

Let us know if you face any difficulty.

[renliangli]

Short answer

Customise disconnected: Add hook of test_station_mode_connect() here

Long answer

1. Doc: Control path understanding
2. Doc: You would anyway arrive here through above link, just to point, Event Handler APIs
3. Doc: C demo Code: C demo -> test.c I think you are already past this.
4. Code: Event callbacks registered here
5. Code: Event callbacks hooks: https://github.com/espressif/esp-hosted/blob/250e29294a740a45dd853115a25b62f1b2cfc51b/esp_hosted_fg/host/linux/host_control/c_support/test_utils.c#L109-L147
6. Customise disconnected: Add hook of test_station_mode_connect() here

Note

1. Try to use async event handlers when using in event handlers. We faced some issues in past for 'sync' handlers when used in event handlers. Except event handler hooks, in general, preference should always to 'sync' APIs.
2. Diff between sync and async: In Async, you register response callback. In sync, you do not register response callback.

Let us know if you face any difficulty.

Your method is to listen for the disconnection message and then restart the connection on the host side.

What I want is for the ESP32 chip station to be able to reconnect to the previously set AP hotspot by itself when rescanning the hotspot.

[mantriyogesh]

What I want is for the ESP32 chip station to be able to reconnect to the previously set AP hotspot by itself when rescanning the hotspot.

Just to understand this clearly, so do you mean that one every reboot, esp should auto connect to the prior AP (or router) it was connected to. This should happen even when host is not triggering connect explicitly.

If host triggered connect with new credentials, these new credentials should become default credentials.

Is this the complete context? Anything I missed?

[renliangli]

What I want is for the ESP32 chip station to be able to reconnect to the previously set AP hotspot by itself when rescanning the hotspot.

Just to understand this clearly, so do you mean that one every reboot, esp should auto connect to the prior AP (or router) it was connected to. This should happen even when host is not triggering connect explicitly.

If host triggered connect with new credentials, these new credentials should become default credentials.

Is this the complete context? Anything I missed?

In addition to reboot, there is another scenario where the station disconnects when the signal is poor, and the ESP32 chip can automatically reconnect when the signal is restored

[mantriyogesh]

The main intention is that host should be notified on disconnect as soon as possible.

May be we retry 1-2 times and then send the disconnect to host.

The main problem here is that host wouldn't even know that the network is disconnected.

This is a typical ownership issue. In hosted ideology, we intend to control slave from host and host should be always and ASAP consistent with esp state. In general, host should auto-connect on receiving the disconnect. ESP cannot send disconnect notification to host and at the same time, retry connecting without host knowing about it. Host would also trigger to connect (basically both parties start to issue connect) at the same time as that of esp, then the state machines would go for toss in esp_wifi.

As workaround, What we can do, is introduce some MACRO, AUTO_DISCONNECT_AT_SLAVE in slave_control.c to auto connect on disconnect, by default disabled. AUTO_DISCONNECT_AT_SLAVE_TIMEOUT and AUTO_DISCONNECT_AT_SLAVE_RETRY

When this macro is enabled and flashed, the slave would try to reconnect with above config, before sending the disconnect notification to host.

[!NOTE]

Word of caution: Unless this disconnect is received at host, host still thinks that it is connected (which is or should be transient state, but still invalid state)

Please let me know if this covers the scenario?

[renliangli]

right

[mantriyogesh]

We will make this change and notify you, once fixed.

[renliangli]

The Station connect SoftAp was successful, why didn't receive the STA-Connected event ?

[mantriyogesh]

The Station connect SoftAp was successful, why didn't receive the STA-Connected event ?

This is little confusing, are your using ESP softap (softap mode) ? or using external AP (station mode) ?

WRT station mode if you are triggering connect, it is going to send back the response (in both sync and async)

In sync way of connection, if the APIs is not returned till the time AP is either connected / failed to connect. In async way of connection, your response callback would be called with appropriate response (connected or failed).

As in manual way of connect, you are getting the connection successful or failure, the event was not triggered.

The 'Connected' event is treated for non manual (auto disconnect->connect) case.

[mantriyogesh]

You can check https://github.com/espressif/esp-hosted/blob/a4a5f00923b45f11d833a3631768f8f7ad1df868/esp_hosted_fg/esp/esp_driver/network_adapter/main/slave_control.c#L150-%3EL162

see the WIFI_HOST_REQUEST_BIT

[renliangli]

The Station connect SoftAp was successful, why didn't receive the STA-Connected event ?

This is little confusing, are your using ESP softap (softap mode) ? or using external AP (station mode) ?

WRT station mode if you are triggering connect, it is going to send back the response (in both sync and async)

In sync way of connection, if the APIs is not returned till the time AP is either connected / failed to connect. In async way of connection, your response callback would be called with appropriate response (connected or failed).

As in manual way of connect, you are getting the connection successful or failure, the event was not triggered.

The 'Connected' event is treated for non manual (auto disconnect->connect) case.

station mode. (auto disconnect->connect): Is this supported now ?

[mantriyogesh]

No, if you are referring to auto connect right from slave (without informing host). The auto connect i referred here is through host.

https://github.com/espressif/esp-hosted/blob/a4a5f00923b45f11d833a3631768f8f7ad1df868/esp_hosted_fg/esp/esp_driver/network_adapter/main/slave_control.c#L128

Here, in macro , we just need to call up esp_wifi_connect(); for auto connect with max retries. Once retry exhausted, send the event to host, to take further action from host side.

As in commit https://github.com/espressif/esp-hosted/commit/c7acb70d8b25b6a4f39dda4ffff42275e9aba13b, already, slave is saving the SSID-Password in NVS(encrypted flash), esp_wifi_connect() should retry the same SSID and password from NVS.

But care should be taken to not waste a lot of time, in retries. As host is unaware of this disconnection.