ESP32 Forum

Environment
I'm working on an ESP32-S3 project which uses FSPI and HSPI via the GPIO matrix. I'm communicating with an ADS8688 using the HSPI which operates in Mode 1 (sample on SCK falling edge) at 1MHz.

I use the esp-idf framework (4.4.7) to setup the bus, device and run half-duplex transmissions with DMA.

Problem
After much head scratching I've discovered what I believe to be a delay between SCK falling and MISO being sampled. I've proven this by scoping the transfer, and noting what the ADC is outputting (approx 0x8000, the mid point of my ADC counts) vs what is sampled (approx 0xFFFF or 0x0000).

I've ascertained that a delay in sampling at the MCU would cause this, leading to left shifting the whole thing. The MISO holds for a max of 20ns after the SCK falling, hence my concern. See below.

Things I've Tried

• Disabling use of DMA
• Not using dummy cycles
• Increasing the SCK - concerningly I get closer to what I expect at 15MHz vs 1MHz.
• Altering the gpio drive capabilities - no effect.
• Adding capacitance to slow the signal & use mode 0 - this is in fact how it was (incorrectly) working previously. Again proving what I'm experiencing acquiring the correct MISO bit. This, however, is what I would call a bodge.

Question
Since I'm using HSPI via the GPIO matrix, would this add enough of a delay to cause this problem? Is there anything I can do in firmware to reduce it? I'm currently using FSPI for my display but perhaps I'd be better using it for my ADC (and MAX31856 ICs)?

Thanks

The attached is what points me towards using FSPI as opposed to HSPI, but then it contradicts this statement earlier on the page..

When an SPI Host is set to 80 MHz or lower frequencies, routing SPI pins via the GPIO matrix will behave the same compared to routing them via IOMUX.

Which is true?

To anyone else with this problem, have a look at these seemingly identical issues:
https://github.com/espressif/esp-idf/is ... 2834392590

viewtopic.php?t=36723&start=10

https://github.com/espressif/esp-idf/issues/7825

The solutions seem to be:

• In half duplex mode, transmit in mode 0/1 and receive in mode 2/3 by re-initialising in between.
• Fix the problem in hardware using a delay, latch or similar.

Maybe try playing around with input_delay_ns (possibly with 'inverted' clock phase to achieve a 'negative' delay from the falling edge), and/or sample_point.