ESP32 FG driver, connected through SPI,ESP32C3 as AP, iperf testing An error occurred.

[244219195]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Provided a clear description of your suggestion.
• Included any relevant context or examples.

Issue or Suggestion Description

Using ESP32 FG driver, the host is ARM ported to Linux system, connected through SPI, ESP32C3 as AP, and a laptop device connected to it. During iPerf testing, it appeared that the streaming time exceeded 1000s. Stop testing, restart testing, and find that the speed has become 0.
During daily use, there may also be situations where the connection is successful but WiFi messages cannot be sent or received normally.
What logs are needed to determine whether it is an ESP32 forwarding issue, a Linux side processing issue, a Linux side ESP32 driver issue, or ESP32 memory exhaustion?
I will capture and submit it for analysis.

Analysis ideas. At the current stage, a single packet capture was performed using Wireshark to capture packets from the PC. It was found that the ping packet was sent out 2 seconds later, but the host side used tcpdump to capture it. After 60 seconds, the host received the ping packet sent by the PC and immediately returned it. The PC also received the returned package.however ，The delay of ping is too long

[mantriyogesh]

In general, root cause need to be found if the link is always slow or not. Please run transport throughput test in both (Rx & Tx) directions to identify if any link issues (without involving wifi) exist or not.

43 sec RTT being reported doesn't seem practical for ping utility, ideally it should have 'timed out' in this case. so cross-check with sniffer log, is the log showing incorrect or there is really a problem.

Also, please cross-check the porting document for some porting guidelines being followed.

I highly doubt this big RTT is possible to treat as response.
We had some recent fix 531.patch.txt.zip which would work on esp-hosted latest master 50f9444 +. but, in your case this fix is needed or not, first need to be cross-check as mentioned above.

During daily use, there may also be situations where the connection is successful but WiFi messages cannot be sent or received normally.

Can you check if the wifi was disconnected by router silently? If the connection was disconnected, host would also get events of disconnected, if C demo application was running & subscribed to disconnection event.

[244219195]

The WiFi connection has not been disconnected.It is still connected, but the ping delay is very high.

[mantriyogesh]

1. Please cross-check if data-ready interrupt and handshake interrupts are triggered correctly from slave to host.
2. Check the jumper cable lengths and grounds are connected. Worth to check porting guide (link in prior comment)
3. Please test raw transport throughput test first, to get to the bottom of things.
4. Can you please check the CPU loading while pinging? 'idle' column in top command may help, to understand current load. Also, any patterns on CPU loading, specific thread loading, any specific CPU loading?
5. Does setting static IP differ anything

Textual logs :

• ESP
  • minicom or idf.py monitor logs
• Linux:
  • dmesg from system boot up
  • demo app request and responses
  • For extra logging (please note extra logging may slow the packets and should not be used in production) : spi_debug_logs_non_built.patch

Git commits:
Share git commits used both places. We recommend using latest master code base at both sides.
Ensure the same git commit used at esp and linux.
Please share any code changes in patch form if any changes other than GPIO numbers are done either side.

[244219195]

OK,I will try it.and feedback you soon.

[244219195]

when i use the spi_debug_logs_non_built.patch ,ethap0 will disappear，ESP32 log show dump.
here are log for it.

[244219195]

esplog.zip

[244219195]

I also want to lease run transport throughput test in both.however have some thing wrong for build it .

[mantriyogesh]

the debug logs are for last sort. what happened for other inputs till now?

[mantriyogesh]

#523 (comment)

#523 (comment)

[mantriyogesh]

The excessive logging may affect the normal working.
That is the reason the watchdog is triggered.

The logs could be lowered, specially, in ESP_LOG_BUFFER_HEXDUMP

But the question is that without logs, did you cross-check other things mentioned?

The debug log is just to understand if the packets are flowing and they are correctly sent. in normal logging, we cannot have these big prints. it would drastically lower throughput ot RTT. also it may point to some possible issues, which are not there due to incorrect buffers being printed.

debug logs patch is not fix as mentioned earlier..

[244219195]

1. Add ESP32 to print out ICMP ping messages immediately upon receiving them, and determine whether there is an ESP32 receiving exception based on the time interval printed out.
2. Check the mechanism of ESP32 forwarding and determine if ESP32 forwarding is abnormal
3. Check again whether ethap0 immediately receives the ping message after ESP32 forwarding is completed. Determine whether it is a processing exception on the AP side.By using the above method, investigate the relevant pathways.

By triggering, print the corresponding log and determine the problem. So add differentiated logs based on the current driver to reduce printing.

How can i do this?

[244219195]

[mantriyogesh]

Are you using raspberry Pi?

[mantriyogesh]

If not, please check the porting guide, which mentions to port rpi_init.sh.

Additionally, I want to bring to your attention, rpi_init.sh has some functions starting with port_XXX(). These need porting.

porting guide

[mantriyogesh]

[244219195]

ok ,I will check it again

[244219195]

I was not use raspberry Pi.I need some time to build it .maybe it will spend time.

[mantriyogesh]

I think you have already ported it. All I am asking is just to cross check if you have done anything differently.