SPI Master fails to read MISO correctly on Mode 3

[martins]

So yeah, just to summarize: S3 on lower SPI frequencies seems to sample MISO data too late. Adjusting params like .input_delay_ns or .dummy_bits should help to solve this, but does not and in fact, does the opposite - only seems to make things worse.

Using SPI_DEVICE_NO_DUMMY flag overrides the internal logic and seems to have best results, just not good enough, even when explicitly using .dummy_bits = 0 and .input_delay_ns = 0.

That in the end might seem like S3 samples data on wrong edge, but in fact it is just the delay - this may or may not be OP's and chrises situation.

Also, there is currently (IDF v5.1.2) a condition for targets other than regular ESP32 in spi_get_timing() and spi_get_freq_limit() stating:

Code: Select all

//TODO: IDF-6578
    ESP_LOGW(SPI_TAG, "This func temporary not supported for current target!");

So I wonder if the IDF-6578 has something to do with anything.

[chris6347]

Thank you for the analysis martins!

After all there seems to be a major bug here!

It is confirmed that the SPI MISO sampling behavior clearly differs from the description in the manuals. This makes a vast range of SPI devices unusable at the moment with the ESP32-S3 because many devices don't have the free selection of SPI clock rates above 15MHz or SPI Mode 2.

Is there a better way to bring this bug to the attention of Espressif? I see little to no engagement here from them...

[avsteele]

I just got bitten by this bug as well.

The ADC (AD7193) uses SPI mode 3 and uses MISO to signal data ready to be read. It pulls it low when data is ready and high about 50 ns after that data it is read out.

Because the ESP32S3 does not sample at SCK rising, but at some time later, it always read the last bit of data as '1'!


Is there any known way in code to reduce this delay?