Page 2 of 2
Re: SPI slave driver, last 4 Bytes missing (using DMA)
Posted: Mon Jan 14, 2019 3:14 am
by ESP_Sprite
Not that I know. You may be able to use the non-DMA mode up to a point, but that only works up to a limited amount of bytes...
Re: SPI slave driver, last 4 Bytes missing (using DMA)
Posted: Mon Jan 14, 2019 12:21 pm
by squonk11
The non-DMA mode (just using the internal buffer of the ESP32) unfortunately is not a solution for me because I need to receive up to 114 bytes and the internal buffer of the ESP32 is only 32 bytes.
I am wondering if it might be possible to activate an interrupt instead of a DMA transaction. In order to check this I was studying the spi_slave.c driver sources. But for me it is not clear how the HW of the SSI works in detail. Is there some deeper description as given in the ESP32 Technical Refernce Manual?
Re: SPI slave driver, last 4 Bytes missing (using DMA)
Posted: Thu Jan 17, 2019 5:02 pm
by squonk11
@ESP_sprite : do you know if there will be a new silicon version of the ESP32 with this issue fixed or at least a workaround in ESP-IDF? If not I will need to switch to a different chip because a SPI slave interface suitable for an arbitrary number of incoming data bytes is mandatory for my project.
Re: SPI slave driver, last 4 Bytes missing (using DMA)
Posted: Sat Jan 19, 2019 3:40 am
by ESP_Sprite
We are working on new silicon, and we're very much aware that the SPI in the ESP32 is not perfect... we're trying as hard as we can to get the most common idiosyncracies in the current SPI peripheral out of the design, and I'd imagine this is one of them.
Re: SPI slave driver, last 4 Bytes missing (using DMA)
Posted: Sun Jan 20, 2019 12:54 pm
by squonk11
@ESP_sprite : Is there a schedule when the new silicon is available? Will it be just a new step of the ESP32 or will it be a feature enhanced version of the ESP32?
Re: SPI slave driver, last 4 Bytes missing (using DMA)
Posted: Fri Jan 25, 2019 4:12 am
by ghazel
ESP_Sprite wrote: ↑Sat Jan 12, 2019 5:24 am
As I said before, for people who run into issues like this: check your /cs signal. The SPI slave logic assumes the /cs signal goes high after the transaction is finished. If for whatever reason (clock slew, difference in wire length, whatever) the ESP32 sees the /cs signal going high before the transaction is done, it aborts the transaction in a weird way that can cause the last 4 bytes to get corrupted or not written.
I am also encountering this issue, and I verified with a signal analyzer on the ESP32 side that the /cs signal goes high well after the clock is done and the transaction is finished. Yet, the last four bytes are still missing.
https://github.com/espressif/esp-idf/is ... -456285033