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 orde...

The information about the amount of transfered bytes from the master is stored in the second byte of the transferred telegram. In order to read this I need to receive the first two bytes separately (or byte by byte). Is there any possibility to achieve that? Even if that needs to be done by polling?

Thanx @zotikus, this design peculiarity is described here: https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/spi_slave.html with the statement: Also, master should write lengths which are a multiple of 4 bytes. Data longer than that will be discarded. Unfortunately I ha...

I am quite sure that my problem is related to this statement: Also, master should write lengths which are a multiple of 4 bytes. Data longer than that will be discarded. which can be found here: https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/spi_slave.html . Unfortun...

Thank you for providing your source code! But for master mode now the problem seems to be fixed also in the esp-idf sources. For the slave mode the problem still exists and unfortunalely I urgently need a solution. Currently I am working on a totally stupid solution: I am trying to emulate an SPI sl...

@michprev : are you willing to share your code of your spi driver? I am currently stuck with the problem that the spi slave driver from Espressif has the problem that in DMA mode for certain telegrams some of the received bytes are missing. So I am searching for another solution.

Hello, I read that you suggest to read bytes from the slave SPI via polling: -Using polling, if you don't mind the CPU being busy while waiting, rather than go do something else. Do you have sample code for that? AFAIK Espressif is currently only supplying a driver SW which is suffering from a desig...

@trancefreak : did you find a solution or workaround for this problem? Unfortunately I encounter the same problem...

@paul719 : did you find a solution for this problem? I am having the same problem. Is there some workaround?

In the driver source for the SPI interface I see in spi_common.c : Does this imply that there might be a v2 silicon in progress which fixes this problem?