SPI master von v5.1

[maierkomor]

Hi,

I am seeing incorrect SPI transfers, when switching off unicore support for ESP32-S3. I.e. I turn on multicore support by disabling CONFIG_FREERTOS_UNICORE, which also changes a set of dependent configuration settings.

The SPI in use is SPI2_HOST configured with SPI_DMA_CH_AUTO.

The effect on an ILI9341 is that instead of valid frame updates, I get noise that seems to be sequentially written to a part of the display, moving from transfer to transfer over the whole screen instead of updating the same part of the screen in the upper area.
I switched to v5.1 for multicore support, now it looks like I cannot use it. I have found no SPI configuration that seems to work.

Any ideas, how to solve this problem? Is this a known issue? Do you need an SPI trace from a logic analyzer?

Regards,
Thomas

[ESP_Sprite]

Can you post (preferably whittled-down version to the minimum needed to show the issue version of) your code, so we can look at it and try to replicate the issue?

[maierkomor]

Well, reducing the code to a bare minimum is difficult, as to reproduce the problem, you need the driver for ILI9341, fonts, and an app does some rendering and screen updates. Additionally, you will need to replicate the hardware setup. I.e. SPI and CS pins etc..
Nevertheless, I can provide you a source package that can be build directly with the idf.py command, but includes a lot more disabled code.
The issue seems also to be limited to larger block transfers. I am not sure about the relation of DMA.

Initializing the SPI without SPI_DMA_CH_AUTO also causes problems due to the SPI driver rejecting the transfer telling that the buffer is too big when compared to max_transfer_sz, although all buffers are smaller than this limit.

Do you want me to send this package? My tests are with TAG v5.1.

Where should I send the package? I don't really want to upload it here directly to the forum.

Thanks.

[maierkomor]

Concerning the maximum transfer size, the message was not regarding max_transfer_sz but shows up as follows, when DMA channel is set to something else than SPI_DMA_CH_AUTO:
E (3157) spi_master: check_trans_valid(775): txdata transfer > host maximum

The transfer size in that case is 4096. Same problem with a transfer size of 1024. I.e. it does not work for me without SPI_DMA_CH_AUTO. With that setting the output to the screen is incorrect if UNICORE is disabled. Just switching that settings, makes all these problems go away.

[MicroController]

instead of valid frame updates, I get noise that seems to be sequentially written to a part of the display, moving from transfer to transfer over the whole screen

Sounds like the tx buffer memory is freed/overwritten by unrelated code before the SPI transaction is finished. Could that be happening in the application code due to a timing/synchronization issue?

[maierkomor]

The frame buffer and transfer buffer are allocated once at the beginning and used over the whole execution time. The same code runs finde in multi-core mode on an ESP32 with IDF v4.4.4. Looking at what is written to the screen, it seems like there is some other issue. For me it looks like a completely broken SPI configuration, as the screen update is not happening where it should be and the contents is completely broken.