Use fpga sdio host and esp sdio slave to communicate, but the slave does not respond (IDFGH-16997)

[phoenix9668]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

My development environment is win11, esp-idf v5.5.1.
My goal is to use Xilinx FPGA to build a host driver for esp32c5 sdio slave.
Before that, I verified that the sdio host example of esp32s3 and the sdio slave example of esp32c5 can communicate normally, including registers, interrupts, and fifo.
Then I used a logic analyzer to record the correct timing. According to this timing, I started writing Verilog code.
The first command was SDIO reset: CMD52(Write 0x6 = 0x8), I sent this command to esp32c5 in strict accordance with the timing, but did not receive response (r5). I tried adjusting the delay of cmd, but there was no response.
In the picture, I can see that there is a response using esp32s3, but there is no response when sent by FPGA.
I would like to ask if anyone has relevant experience. Where is the above problem?

[suda-morris]

What is the IO level of the signals from the FPGA? maybe it's not 3V3?

[suda-morris]

what if you connect the FPGA to a real SD Card, can you see the response?

[phoenix9668]

it's 3V3!
I observed clk and cmd with an oscilloscope and found that the signals emitted by FPGA and esp32s3 were basically the same. The FPGA signal had more glitches. I didn't understand the sdio slave timing requirements of esp. I tried configuring the clock edge control written in the document, but it was of no use.

[ginkgm]

Hi @phoenix9668 ,

Sending CMD52 before CMD0 is the suggest reset workflow by the spec. (PartE1 SDIO Spec v3.0) 3.1.2 Initialization by I/O aware Host. Figure 3-2. And section 3.4.1.

If the reset starts with CMD52 first, then CMD0, the card have the chance to reset its SDIO functionalities upon receiving CMD52.

The other way around, if host send CMD0 first, or the card start from a power-up state, the card should ignore CMD52. This means the very first CMD52, after the card is powered up or after receiving a CMD0, will timeout. The host should treat this as a normal behavior.

[phoenix9668]

I sent CMD52 before CMD0.

The previous problem should be that my FPGA program sent CMD52 almost immediately after starting. Then I delayed it for 2 seconds before starting the initialization process. Then there is a high probability that CMD52 has a response(As shown in the picture). My screenshot shows that the timing after delayed sending is most likely normal!

Occasionally, it may not be related to you saying that CMD0 is sent first or the device is power-up.

[phoenix9668]

thanks@ginkgm, this issue solved!