The current behaviour is:
The WiFiUDP::write() method prepares the ESP32 to send a datagram. After the AT command is sent to put the ESP32 to sending mode, the library waits for the handshake signal, then checks if the SPI is in "ready to write" mode, then the library sends the contents of the datagram and the udp frame is sent over wifi.
However, it is legal that a UDP frame is received at any time, including in the middle of a sending process. What currently happens is:
at the time the write() method waits for the handshake signal, if an incomoing udp frame arrives, then the handshake signal rises, and the write() method expects the SPI state to be "ready to write", but this time it is "ready to read", so the write() method returns with an error state.
The write() method should instead receive and store the incoming frame, then resume waiting for the handshake flag until the state is "ready to write".
I have pasted below the reply I got from the Espressif forum where I first posted for help on this subject:
According to the design of SPI AT(https://docs.espressif.com/projects/esp-at/en/latest/esp32c3/Compile_and_Develop/How_to_implement_SPI_AT.html#handshake-pin), the slave read and write are linear and cannot be carried out simultaneously. When both read and write occur at the same time, the slave will arbitrate the subsequent actions. In your scenario, the slave has already indicated that it needs to perform a read operation first. Therefore, the master must first read the data, and then the slave will again send an interruption notification to the master to indicate that it is ready to write data.
The current behaviour is:
The WiFiUDP::write() method prepares the ESP32 to send a datagram. After the AT command is sent to put the ESP32 to sending mode, the library waits for the handshake signal, then checks if the SPI is in "ready to write" mode, then the library sends the contents of the datagram and the udp frame is sent over wifi.
However, it is legal that a UDP frame is received at any time, including in the middle of a sending process. What currently happens is:
at the time the write() method waits for the handshake signal, if an incomoing udp frame arrives, then the handshake signal rises, and the write() method expects the SPI state to be "ready to write", but this time it is "ready to read", so the write() method returns with an error state.
The write() method should instead receive and store the incoming frame, then resume waiting for the handshake flag until the state is "ready to write".
I have pasted below the reply I got from the Espressif forum where I first posted for help on this subject:
According to the design of SPI AT(https://docs.espressif.com/projects/esp-at/en/latest/esp32c3/Compile_and_Develop/How_to_implement_SPI_AT.html#handshake-pin), the slave read and write are linear and cannot be carried out simultaneously. When both read and write occur at the same time, the slave will arbitrate the subsequent actions. In your scenario, the slave has already indicated that it needs to perform a read operation first. Therefore, the master must first read the data, and then the slave will again send an interruption notification to the master to indicate that it is ready to write data.