ACMD41 Stuck Busy, works with i_card_detect tied to Constant 1, fails with Real card detect pin

[kilicyusuf1]

Hello,

I am running the sdio core on a Nexys A7 (Artix-7) with MicroBlaze (bare-metal, no OS). I have OPT_CARD_DETECT = 1 enabled in both scenarios described below.

I observed a critical difference in behavior based on how the i_card_detect port is driven:

Scenario A (Working): i_card_detect is tied to a Constant 1 in the Block Design.

Result: Initialization works perfectly. ACMD41 returns Ready (0xC1FF8000).

Scenario B (Failing): i_card_detect is connected to the physical CD pin (via a NOT gate to ensure Active High).

Result: CMD8 works, but ACMD41 returns BUSY (0x00FF8000) indefinitely.

I verified the polarity is correct (High when inserted). Debug prints show the core receiving the signal correctly (PRESENTN and REMOVED bits toggle as expected).

It seems the internal state machine gets stuck in a Busy state when dealing with the real pin, whereas a Constant 1 bypasses this issue.

Logs (Scenario B - Failing with Real Pin):

PHY=C99C00FC SERDES=00000000 DDR=00000001
idle cmd=00004040 removed=0
idle cmd=00004040 presentn=0
CMD0:    SEND_GO_IDLE
  Cmd:     00000040
  Data:    00000000
after idle cmd=00000040 removed=0
after idle cmd=00000040 presentn=0
[CMD8] pre  sd_phy=C99000FC
CMD8:    SEND_IF_COND (000001A5)
  Cmd:     00010108
  Data:    000001A5
after ifcond cmd=00000040 removed=0
after ifcond cmd=00000040 presentn=0
CMD55:   SEND_APP_CMD
  Cmd:     00010137
  Data:    00000120
ACMD41:  SEND_OP_COND : 00000000
  Cmd:     0022813F
  Data:    00FF8000
CMD55:   SEND_APP_CMD
  Cmd:     00010137
  Data:    00000120
ACMD41:  SEND_OP_COND : 51FF8000
  Cmd:     0022813F
  Data:    00FF8000
[ACMD41] i=00000001 ocr=00FF8000 cmd=0022813F removed=00000000 presentn=00000000
CMD55:   SEND_APP_CMD
  Cmd:     00010137
  Data:    00000120
ACMD41:  SEND_OP_COND : 51FF8000
  Cmd:     0022813F
  Data:    00FF8000
. . .
. . .
. . .

Logs (Scenario A - Working with Constant 1)

PHY=C99C00FC SERDES=00000000 DDR=00000001
CMD0:    SEND_GO_IDLE
  Cmd:     00000040
  Data:    00000000
[CMD8] pre  sd_phy=C99000FC
CMD8:    SEND_IF_COND (000001A5)
  Cmd:     00010108
  Data:    000001A5
CMD55:   SEND_APP_CMD
  Cmd:     00010137
  Data:    00000120
ACMD41:  SEND_OP_COND : 00000000
  Cmd:     0022813F
  Data:    00FF8000
CMD55:   SEND_APP_CMD
  Cmd:     00010137
  Data:    00000120
ACMD41:  SEND_OP_COND : 51FF8000
  Cmd:     0022813F
  Data:    00FF8000
CMD55:   SEND_APP_CMD
  Cmd:     00010137
  Data:    00000120
ACMD41:  SEND_OP_COND : 51FF8000
  Cmd:     0022813F
  Data:    C1FF8000
READ-OCR: OCR = C1FF8000

. . .
. . .

I also added a debouncer module before the sdio module but I observed still the same behavior.

Is there a specific requirement for the i_card_detect signal that I might be missing?

Thanks.

[ZipCPU]

I don't recall seeing this bug before, so this is new to me. I do know that it can take a while for the busy signal to clear--but that doesn't seem to be your issue.

Likewise, there's a bit of a debouncer already in the card detection circuitry. That's why there's a counter. Any time the card detect goes low, the counter starts. While low, the counter is held to zero. Once it releases, the counter is supposed to deal with any bouncing. I'm pretty sure this isn't the issue.

Try this: send the SEND_GO_IDLE command twice, see if that helps.

Why? Clearing the card removed signal requires a write to the command register. This also clears an internal reset. That internal reset would prevent commands from being accepted. It could be that there's a race condition between when the card removed signal gets sent, and when it gets applied, and so the GO_IDLE command is ever sent, hence the card never leaves its idle state to start booting up.

Let me know what happens. If this is turns out to be the issue, then we can either adjust the software to force the two commands to be separate (such as sending a NULL command to clear the card removed bit), or adjust the RTL to remove the race condition.

Dan

[kilicyusuf1]

Hi Dan,

I appreciate the suggestion regarding the race condition and the internal reset logic.

I implemented the fix exactly as described, but unfortunately, it did not resolve the issue. The ACMD41 Busy state (0x00FF8000) persists indefinitely when using the real pin.

Here is a summary of what I have attempted based on your feedback:

Double SEND_GO_IDLE: I modified the init sequence to call sdio_go_idle twice with delays in between.

Manual Register Write: I tried manually writing 0x00080000 (to clear the Removed bit only) and 0x00080040 (Clear Removed + CMD0) directly to the register before the driver's standard initialization routine, adding generous delay loops to allow the internal reset to settle.

I haven't had the opportunity to investigate the RTL implementation in detail myself yet, so I wanted to share these findings to see if they point to a specific module or signal in your design.

Thanks.
Yusuf

[ZipCPU]

Can you read the CMD register before issuing the IDLE command, to verify that the card removed bit has actually been cleared?

There is a debug port coming out of the sdfrontend. I may need you to trap the interrupt indicating GO-IDLE completion, and use that as a trigger when capturing this data. This could help us verify that the GO-IDLE command was truly and properly sent to the SD card.

Dan

[ZipCPU]

Also, the SDIO specification recommends waiting the maximum of (1 ms, 74 clock cycles, and supply ramp up time) prior to interacting with the SD card. My IP does not guarantee any of these. Therefore, let me recommend: 1) you disable clock shutdown when no card is present, 2) once a card is detected, you clear the removed card flag and then wait 1ms.

Let me know if this helps.