ESP32 Forum

Hi,
I have a project which uses an epaper display type inkplate 6Motion from the Soldered company. It is fitted with a ESP32 as a coprocessor to handle wifi communication, and the whole is supported by a library supplied by the manufacturer.
The library uses the SPI AT protocol, that is, a SPI is used along with a GPIO configured as an output at the ESP32 side and an interrupt input on the main microcontroller side, according to the SPI AT documentation (https://docs.espressif.com/projects/esp ... PI_AT.html).
I experience transmission failures, and after some investigation, I can narrow my search to the way incoming UDP frames are stored in a buffer.
My project is a remote display that connects through wifi to a system. The system sends a 40-byte UDP frame every 500 ms, regardless of someone is listening or not.
When my application receives one frame, it processes it and returns a 22-byte UDP frame, that is, for each frame received there will be one frame transmitted.
The epaper display requires a periodic refresh, about every 50 seconds, and a refresh takes 750 to 1000 ms.
The problem is that at the time of refresh, the code cannot keep up with the incoming data. When I start the execution, I see that each received frame is correctly processed, with a frame sent in response; and at the time of refresh, I see two frames being read from the ESP32 in a row (at a few ms interval).
However, after a few minutes, after one refresh I see only one frame read from the ESP32, and the write function that is called to send the transmitted frame fails. Then I found the cause of the failure: in the write function, the ESP32 state is "ready for read" instead of "ready to send".
This, added to the fact that only one incoming frame was read instead of two, point to a problem with the buffering of incoming frames when more than one frame has been received and not read by the application.
I could not find any rule related to the buffering mechanism or the handling of incoming frames.
Is there such a document? Who knows how the buffering is handled?
I also observed once the following behavior: three times in a row only one incoming frame was read instead of two, and the fourth time four frames were retrieved in a row by the microcontroller, suggesting that three unread frames were somehow stuck in a buffer, and eventually let go by the ESP32.
Thanks for help.
Jean-Marc

Hi @PhonoESP ,

Thank you for the detailed description. I'd like to help clarify a few points:

1. Could you let me know which ESP-AT firmware version you are using, and which AT commands your application sends? This will help us understand the exact behavior.

2. If you have configured passive receive mode (via AT+CIPRECVTYPE), the behavior you described may be related to a known issue (#994). The master branch already includes improvements to better handle UDP datagram integrity in passive mode. You can refer to the discussion here: https://github.com/espressif/esp-at/issues/994

3. If you are not using passive receive mode, I'd suggest enabling AT debug logs to see what happens inside the ESP-AT when the issue occurs. You can follow this guide to enable AT Network Function Debugging and AT Interface Function Debugging:
https://docs.espressif.com/projects/esp ... _logs.html

The logs should help us understand whether the UDP frames are being buffered as expected, and why the ESP32 state becomes "ready for read" instead of "ready to send".

Please feel free to share the firmware version, the AT commands you use, and the debug logs if available. We'll be happy to help further.

Best regards,
CW

Thank you for answering.
I am actually using a library supplied by the manufacturer of the board that I bought, which includes an ESP32-C3 as a coprocessor to handle the wifi communication. I have the source code, but though I spent quite a few hours reading the source code, I am not yet fully understanding how it works.
1-I do not know the firmware version, whichis not queried by the library.
2-The passive mode is not selected
3-The logging is not selected either. I would need writing extra code on purpose to add to the library, which i currently do not have the time to do.
However, all my work of the last days allowed me to identify the conditions when this behaviour occurs, and a workaround it to have a stable communication despite this problem.
The problem occurred when a UDP frame is received during the process of sending a UDP frame. To alleviate this, I modified the behaviour of the system:

-When the remote dashboard is not connected, the system sends a beacon frame every 1500 ms
-When the remote dashboard is started and ready, it discards any previously received frames
-Then for the next frame received by the dashboard, the dashboard replies by sending a frame immediately (well before the 500 ms are elapsed)
-The system receives the frame from the remote dashboard, and switches to a mode where it does no more send frames in the wild, but waits for an incoming frame, then replies immediately.
-On reception of a frame, the remote dashboard waits for 500 ms then replies. This triggers a reply from the system, so that no frame can be received by the remote dashboard while a frame is being sent.
-If the system has not received a frame for 1500 ms, the system switchs back to the beacon mode where it sends a frame every 1500 ms.

With this mode of operation, I could achieve the required stability, and I will not go any further in understanding my previous problems.

I have a question : currently the remote dashboard checks for a timeout for the incoming frames, and switch to an error state when this occurs. But it does not know whether this is due to the system having stopped sending, or to the loss of wifi connection (for example when the dashboard is too far away from the system). I there a means to query the ESP32 to know whether the wifi connection is still established, to provide a better error handling?

Thanks again for help.

Hi @PhonoESP , thank you for sharing your solution and the detailed explanation. I'm glad you found a workaround that works for you.

Regarding your question about checking the Wi-Fi connection status:

• If you are using the AT firmware, you can use the command AT+CWSTATE? to query the connection state. Additionally, AT+CWJAP? can give you the RSSI (signal strength) when connected.

• If the library uses ESP-IDF directly, you can monitor WiFi events (like connected/disconnected) to detect the status.

For more information, you can visit the ESP-AT documentation and use the chatbot (the little robot icon) on the page:
https://docs.espressif.com/projects/esp ... index.html

Hope this helps. Feel free to ask if you have further questions.

~