ESP32 Forum

Thanks Loboris.

Do you know if the DMA problem was reported formally/officially to EspressIf?

RSN

Thanks Loboris.

Do you know if the DMA problem was reported formally/officially to EspressIf?

RSN

I've only got the response from ESP_Sprite:

My guess is that there is still some remaining state in the spi dma controller that does not get reset when the transmission has ended. Thanks for the hint on resetting the IN part as well; I'm working on spi-master anyway and will include this in the next MR for it.

No worries loboris. Thanks for your work.

I did use the software CS and writing worked but not reading. The clock is lost after Tx is done, it takes some time and starts again, but data gets corrupted meanwhile and the Driver gives wrong values.

I notice ESP-Sprite seems to work at Espressif, hopefully so. A message for him.

The DMA section of the spi-master is really "not working to say the least.

Errors/inconsistencies in the spi-master:

#define THRESH_DMA_TRANS (8*32) defines the max amount of data to Tx or Rx WITHOUT using DMA.
First minor mistakes, is that in some IF conditions its used as <= and in others just < so when fixed to All being <= one can read/write up to 32 bytes without a problem and very consistent.

Passed that point the DMA section gets into play and I cannot find what is wrong. There is no DMA apis that could help detect what the problem could be, but it is absolutely erratic, not trustable if one considers that we could need reading of thousands of bytes from SPI.

Again, WRITING is perfect so maybe something with the Rx setup of the DMA.

There is also another topic where the user complains about DMA problems receiving with another driver (cannot remember which).

Hope it can help to clear some bugs and have a perfect ESP32 IDF.

RSN

Gotcha. As a matter of fact, I'm working on the SPI master code anyway; there should be a fix on Github that addresses the timing discussed elsewhere pretty soon. I'm also working on longer DMA transfers; I'll also build some test cases for long DMA transfers plus WiFi, see if I can reproduce the issue.

No worries loboris, thanks for your work and time.

Maybe you could inform ESP-Sprite of the DMA problem in spi_master.

Regards.

RSN

Hi loboris.

Saw the reply from ESP-Sprite. Good to know.

One question regarding the use of the spi driver (either). If we have TWO (or max 3) devices in the spi chain each with a CS GPIO, how does one access each device? spi_bus_initialize and spi_bus_add_device(VSPI_HOST, &devcfg, &spiX) and the spi(X-Y-Z) one passed as parameter?

Regards.

Yes. The idea is that the spi device handle is essentially all you need to communicate with the device.

May I ask if you tried it with more than one device? Because when I did it did not work at all. It got stuck, holding on the internal time out at ret=spi_device_get_trans_result(handle, &ret_trans, portMAX_DELAY) in spi_device_transmit routine.

After a lot of tracing I found that the reason was that it never did update WHICH device it was using and always wanted to answer to the first device (0). It does add the device just that it always wants to "answer" to device 0, when sending to the xQueueSendFromISR.

Anyway the fix is simple, its in static void IRAM_ATTR spi_intr(void *arg).
All this in spi-master.c for anybody else that might read this.
I've already tested it on 3 devices . Maybe share this with ESP-Sprite.

RSN

Thanks for that! I actually checked multiple devices early on, but did my later testing with just one device... I think a bug may have snucked in then. I'm reworking the SPI code anyway, will add a test for multiple slaves then.

You are welcome. Thanks to you.

RSN