- SPI3 length: 8192, trans length: 8192, pTx: 1073539608, pRx: 1073543708, RxData:
- 03000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003000180000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003000280000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003000300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003000380000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
I have been attempting to get the ESP32 to function as a slave on the SPI bus of my design. The bus is currently occupied by a serial flash device as well (separate chip select signal, of course). I have poured over all the documentation, errata and sample code to get this functionality going. I believe I have configured the SPI3 peripheral properly, including placing all buffers in DMA capable memory and utilizing the default peripheral pin locations to ensure reliable throughput, yet I am seeing some strange behavior.
If I operate the SPI bus without any attempts to access the other serial flash device, the ESP32 appears to respond as expected. However, if I access the serial flash device at all, proper operation of the ESP32 SPI peripheral is not achieved.
The first thing I noticed is that the ESP32 appears to be driving the MISO pin when its chip select is not active (bus access was intended for the serial flash). This is a fundamental failure of the hardware... a search of the forum does not reveal any other complaints about this, so I have to wonder if other users are using a dedicated bus for SPI traffic?
Secondly, I noticed that my post-transfer callback is being triggered after 8192 clocks (1024 bytes) when the bus traffic is 100% serial flash transactions (chip select for the ESP32 is not active). I can replicate this phenomenon if I simply perform a READ of the serial flash contents (the contents of the serial flash are non-zero). The post-transfer callback is receiving spi_slave_transaction_t structure information indicating the total data length was 8192 bits and the transaction data length was 8192 bits, yet the data pointed to by the rx_buffer pointer is mostly zeroes and not representative of the SPI bus data presented by the serial flash. I later determined that the data included some content which reflects the attempted flash addresses that are accessed.
In an experiment, I read 128-byte blocks of data from the serial flash, starting at address 0x00000000. If I execute eight of these operations (total of 1024 bytes read from flash), I get consistent data content in the post transaction callback. A diagnostic dump of this data from my code reveals evidence of what appears to be the incremental address occurring in the data. The triggered event appears to always start with 0x03000000, followed by values of 0x03000080, 0x03000100, 0x03000180, 0x03000200, 0x03000280, 0x03000300 and 0x03000380. These address values correlate with the base address the host was attempting to access on each 128-byte read. A capture of the first block of data from my diagnostic code is shown below.
Could this be a clue to what the hardware is doing internally?
Can anyone corroborate this behavior when operating on a multi-slave bus configuration?
Is there any work-around?
Thanks in advance!
Mark