The SDIO_CK clock is unexpectedly stopping during an eMMC erase command. Why?

[TDK]

I'm trying to erase the entire eMMC chip using an STM32F405.

I send CMD35+CMD36+CMD38 and get the expected R1 response from all 3 commands. After CMD38, the D0 line goes low to indicate the chip is busy erasing. About 1000 SDIO clocks after CMD38, the SDIO_CK clock unexpectedly stops. No other communication is done on the bus and the code is (intentionally) stuck in a while loop. Interrupts are disabled during the entire time.

The above is with a 24MHz clock (or anything 8 MHz and over). If I slow the clock down to 4 MHz, I get the correct behavior. The SDIO_CK clock never stops, the D0 line eventually goes high, and the chip is erased.

The 3.3V rail is solid.

The communication is otherwise working fine. I can read/write to the card at 48 MHz clock. I have read out hundreds of GB with no errors.

This was working fine before. I tested with a different STM32 board and got the same behavior, but I don't have another eMMC onhand to test with. Even so, the SDIO_CK is driven by the STM32, not the eMMC, so I don't think a bad eMMC chip would explain it.

Any idea what's going on? I hope I'm missing something obvious.

[TDK]

Progress. If I instead use blocking functions instead of DMA, this issue doesn't occur. I think the RX FIFO is getting full and the clock is getting stopped because of it, even though DMA/hardware control shouldn't be enabled here. I'll mess with it tomorrow. 1000 clocks is about 32 * 32 bits, which is the length of the FIFO.

[TDK]

The problem was the RX FIFO was being filled up and SCK was paused while the buffer was full. I'm not sure why the FIFO was getting full. Rather, I'm not sure why the DCTRL_EN bit was set. It should probably have been reset a the termination of a prior read. I didn't have time to trace back to where/why it wasn't getting reset, but resetting the DCTRL_DTEN bit prior to the erase fixed the problem.