SDMMC_FLAG_SDIOIT flag not set - SDIO DMA on STMH7B0

[Claydonkey]

I have adhered to the an5200-getting-started-with-stm32h7-series-sdmmc-host-controller-stmicroelectronics.pdf document and have had a good deal of success implementing CMD53 and CMD52 comms with a slave device but there seems to be a problem

The slave device sets an interrupt (request) on DATA Pin 1 which I need to respond to.

I have enabled SDIOIT interrupts and cleared the flags upon initialization of the SDIO.

hsd1 being a pointer (my app requires it to be added on the heap) and SDMMC1 is the Instance.

__HAL_SD_ENABLE_IT(hsd1, SDMMC_IT_SDIOIT);
__HAL_SD_CLEAR_FLAG(hsd1, SDMMC_FLAG_SDIOIT);

I can detect the the pin being set low through polling after/before data has been sent /received using DMA.

Therefore the slave device is behaving as expected but the SDIOIT flag on the STMH7B0 is never set.

I wish to respond to it being set in the ISR and don't wish to poll the pin

void SDMMC1_IRQHandler(void) {
if (__HAL_SD_GET_FLAG(hsd1, SDMMC_FLAG_SDIOIT)) {
... do something
}

Should be simple right?

But the flag is never set.

I sense that this is due DMA transfers doing something behind the scenes - clearing and/or disabling the SDIOIT interrupt. (Either in hardware or in the HAL library).

In addition quoting from STM32MP1-Peripheral-SDMMC_interface_SDMMC.pdf

"The interrupt concept is used to inform the host of changes in the card status using the SDMMC_D1/IRQ pin in 1-bit or in 4-bit data bus mode. SDIO interrupts are sent from the card to the SDMMC host when the card detects an external event. Interrupts are only sent outside the data transfer periods. The SDMMC host detects interrupts sent on the SDMMC_D1 pin once the SDIOEN configuration bit in the data control register is enabled. While the DPSM remains in Idle state and in Busy state between data blocks for DS, HS, SDR12 and SDR25 speed or after the last data block in all speed modes, all low levels on the SDMMC_D1 pin are detected as interrupts from the card to the host."

Maybe someone could explain to me why the flag isn't happening...

[Tesla DeLorean]

Should work, never seen it used. Did find one example where a WiFi card might use it.

At a pin level perhaps as an EXTI. Most I think use the mechanical switch off the socket to determine card arrival / removal

[Tesla DeLorean]

Back-linking for completeness   https://community.st.com/t5/stm32-mcus-products/where-is-the-interrupt-on-pin-d1-for-sdio-handled-by-the-stm32h7/td-p/607401

[Claydonkey]

Sorry @Tesla DeLorean I fear We are suffering the consequences of my hastiness 

@F.Belaid has posted some info in the other post but now this post seems more relevant as his suggestion of making sure the DPMA set to FALSE was already present in my code and the flag is not hailed...

[Claydonkey]

So in addition according to @FBL I have made sure that DPMA is false (both during and after transmissions) but the result is the same

[FBL]

Hello @Claydonkey 

Thank you for the clarification in the second post, 

Normally you can configure the sending of an SDIO interrupt in the SDIO slave even if a transfer is ongoing.

From slave side, could you check it is sending SDIO interrupt to the host during interrupt period?

You may want to use the SDIO slave device with a different host device to see if the issue persists. If the issue does persist with a different host device, then it's likely that there is an issue with the SDIO slave device's interrupt configuration or hardware.

[Claydonkey]

@FBL 

@Tesla DeLorean 

This really led me down the rabbit hole and led to some close scrutinizing the logic analyses.

It turns out that given the D1 interrupt is sent from the slave thusly. (SDIO slowed down to 1Mhz)

The overall throughput is heavily compromised by those 'missed opportunities'

The D1 interrupt is never picked up by SDIOIT (even at this slow speed).

As you can see the D1 interrupt is never sent during the data sequence and therefore according to the SDIO literature - the STM32 should be able to handle the transition. 

1. A suggestion was made to alter the slave firmware to send an OOB interrupt on another pin and capture this as an EXTI on the STM32. This seems an unnecessary addition...

2. Would it be worth considering the following sequence :

1. Disable SDIO after DATA sequence
2. Enable interrupt on pin D1
3. Restart SDIO on:
   a. EXTI interrupt
   b. Timeout of reception of D1 interrupt

Should the clock carry on strobing so as not to irk the slave?

Could the D1 EXTI pin interrupt be set concurrent to the SDIO peripheral running?