Problem Using SPI Slave Mode With DMA (IDFGH-7468)

[ESP_michael]

If I understand wrongly, you are using another host, to access the flash or ESP32 slave alternatively...

Could you check if you have connected ground of three boards together correctly?

And maybe we need the logic analyzer capture on the 4 pins of ESP32 SPI interface to check what's happening..

Michael

[berlinetta]

Hello Michael,

Let me clarify the hardware configuration and the history of my development effort...

We have an existing product which contains a "host" microcontroller acting as the SPI bus master. This design has both a serial flash device and a different radio for IoT communications attached to the SPI bus. We have modified the board to remove the original radio and replace it with an ESP32 module which is "sky wired" into the circuit. In essence, I am developing with the ESP-WROVER-KIT, wiring in the SPI bus, interrupt and handshake signals to the modified production board. The power supply and ground connections to both boards are common.

Initial testing produced problematic operation with attempted communications to both the serial flash and the ESP32. Therefore, I had modified the "host" code to remove any attempted accesses to the serial flash so I could focus on getting the SPI communications functioning properly with the ESP32. I was able to eventually get the ESP32 to respond to the SPI transactions as expected. The ESP32 was triggering the post-transfer callback immediately after the radio chip select signal was de-asserted, and the SPI receive buffer reported the exact size and content of the MOSI data as expected. The content of the MISO signal was representative of what had been queued up for the SPI transfer as well.

More recently, I decided to re-introduce the host code which communicates with the serial flash in an attempt to get the complete functionality of the system restored. I discovered the host was not able to communicate with the serial flash or radio once again. I determined the ESP32 SPI slave was responding to bus cycles that were not intended for it (flash chip select was active, not the ESP32 chip select), so I disconnected the MISO connection to the ESP32 to prevent contention.

Our ESP32 code is designed to queue up a transfer specifying a 1024-byte buffer which allows it to receive the largest possible transaction from the master. Using a logic analyzer to verify the operation of the devices while focusing solely on flash transactions, I determined that the ESP32 SPI slave was triggering the post-transfer callback after 8192 bus clocks (1024 bytes transferred) despite the fact that the radio was never selected. I was able to confirm that the SPI read buffer of the ESP32 slave was reporting the exact MOSI data which was being sent to the serial flash device and the SPI was driving the MISO signal with the data that had been queued.

If I then attempted to strictly exercise radio transactions on the SPI bus, the ESP32 was apparently not responding to the bus transactions directed at it as I expected. I am no longer seeing the post-transfer callback triggered when the radio chip select is de-asserted as it was doing in previous testing. Instead, the ESP32 triggers the post-transfer callback after receiving 8192 clocks from the slave (same behavior as when we were solely addressing the serial flash).

So I am at a loss about why the ESP32 does not appear to be responding to bus cycles in which its own chip select signal is asserted as it was originally doing when I had removed the "host" code which was addressing the serial flash. I do not believe I have changed any of the code dealing with the initialization and configuration of the SPI slave since then, and I have supplied the code modules which I am using to perform the SPI bus transactions.

I have experimented with forcing the radio chip select both active and inactive, with no change in behavior. The ESP32 is acting as if the chip select signal is always active (internally?) or as if the peripheral is not aware of a chip select signal assignment, so it monitors all bus activity.

If you can give me any insight as to what may be happening with the DMA-based SPI slave operations, I would greatly appreciate it. At this point, I am seriously considering transitioning the communications methodology to UART, but I am concerned the UART peripheral on the ESP32 may have similar issues with DMA transfers.

Best Regards,
Mark