ESP AT SPI on C3

[banjoluck]

Greetings,

We would like to use the ESP-AT SPI interface on the C3 Mini. I am seeing some of the expected behavior from the ESP firmware, but there seems to be a catch that I don't understand. I'm attaching a capture from the Salea of the SPI traffic in case you want to look at it with me.

We are sending the command "at+gmr" and then reading back the result. For the purpose of this test, we only read 16 bytes from the ESP at a time. We've done the same test with a larger buffer with similar results.

When we complete the write, we send command 0x7 to end the write. Then, we read-back the status. The ESP reports that we are still in write-mode. We send the command 0x7 again and this time, status returns that we can read data back. We're able to read the first segment of 8 bytes and then terminate the read with command 0x8. The second read of 0xb6 bytes is OK and then we send command 0x8 to terminate. This time, the ESP doesn't change the status and we are told there is still data to read. We read it again, but this time all data bytes are 0xd. We end the read with 0x8 command again, but the ESP never releases the Interrupt line and it continues to return status that there is data to read.

Is there more documentation on the details of this SPI protocol than what we find here:

https://docs.espressif.com/projects/esp ... PI_AT.html

Cheers

[andrew_aus]

Hi banjoluck

You've probably figured this out by now but the handshake is positive edge triggered, not level triggered.

So, the slave status should be read only when you see the handshake line transition from low to high.

Check the source code for how it works. In the AT project search for the file at_hspi_task_esp32_series.c

[banjoluck]

That could be part of the problem. I had, in fact, moved on since there was no response from espressif.

[yake827]

Hi,
I have analyzed your logic analyzer data and I think your problem is that the Master receives the data sent by the AT core, this time Master should not actively read the status, but should wait until the AT core triggers the GPIO interrupt to read.
1. The Master must strictly follow the SPI AT workflow (https://docs.espressif.com/projects/esp ... t-workflow).
2. The master does not have any right to actively read the register, he can only read once after the GPIO interrupt has been triggered.
3. If the master has data, he can actively write to the register, but whether he can write is determined by the AT core. The master must wait for the GPIO interrupt to read the slave to know what to do.

[banjoluck]

Greetings,

I think that the confusing part is that the meaning of GPIO interrupt is not made clear. If the interrupt were level triggered, the capture would represent a reasonable interpretation of the workflow. However, if the interrupt were edge triggered, then the workflow should explain that the interrupt GPIO must be deasserted before it is recognized a second time.

Thanks for the clarification.