我是使用的STM32F103VDT6芯片，TF卡使用的是sandisk class4 4G的。使用的是SDIO+DMA官方例程，单独测试没有发现问题，但是当我开启其他中断时（不管什么中断），比如我开启TIM3定时中断，中断频率为200Hz，中断中执行一个for循环来模拟中断处理，只要for循环的执行时间较长，就会出现TF卡的操作卡死问题，就是TF卡操作一直在等待DMA标志，并且for循环越长出现这种卡死的概率越大，当达到一定程度后TF卡完全不能操作。我大概估算了一下，差不多在中断执行时间达到总时间的20%左右就会明显有卡死现象，达到50%左右就基本上不能正常操作TF卡了。
由于我需要降低功耗，所以将主频降的比较低，4MHz，所以中断处理相对来说就显得执行时间较长，这样我才意识到这个问题，后来直接用官方例程实测，开通一个TIM3中断，执行for循环延时，当达到一定程度后，可以重现这个问题，所以我觉得应该是固件库或者是硬件的原因，不知道你们有没有发现这个问题，可以的话你们也可以这样测试一下，看能否重现这个问题，要是能解决的话，希望帮忙解决一下，要是这个问题得不到解决的话，我们只能放弃使用这个芯片了。

具体这个问题，我没有遇到过，不过能从你的描述来看，可能是你自己的程序问题：
1、用官方例程来测试没有问题，至少说明硬件和软件出现问题的几率比较小
2、加中断后，出现问题。这就很可能是中断处理的问题。
3、如果你没有加操作系统的话，就是你采用前后台的系统结构。
（1）把定时器的中断处理时间尽量减少（就是在中断响应函数执行时间缩短）
（2）把中断过程处理的for循环移到中断外面来处理，比如main函数里面，在中断函数只要做一个标记就可以了。
从你描述的过程中，应该是中断执行时间太久的原因（for循环越长出现这种卡死的概率越大），这个很可能是系统错过了某个事件。
不知道你的中断的优先级是怎么配置的。也有可能是让DMA中断不能及时响应。

首先谢谢楼上的。
首先中断中没有涉及任何事情，只是延时问题。DMA是使用例程的，没有中断，是使用的查询方式，只有SDIO中断，并且SDIO中断的优先级最高，可以嵌套TIM3中断，整个系统就只有这两个中断。我没有使用操作系统，完全使用的是SDIO+DMA官方例程测试的。当然，把中断中的执行代码拿到中断外，这个问题就不会出现了，但是我的主频很低，中断中稍微多一点事务处理就很可能触发这个问题，我现在已经尽量将可以移出的处理移出来了，但是这个并没有找到问题的根源，说不准他就一定不会在什么时候出问题，而且以后系统需要扩展功能的话，这也是一个暗藏的问题。
我的意思是，即使在中断处理时间较长的情况下（条件比较苛刻的情况），也能保证程序不被卡死，因为只有这样才能保证系统的可靠性。

你说的也是，这是个定时炸弹。
你可以详细描述下什么是卡死？
1、你确认一下，SDIO包括STM32的驱动中是否有循环等待某个标志位
2、你的应用程序中（SDIO相关的）是否有循环等待某个标志位。
3、错误处理：
关于DMA，如果有需要的话，每次使用前，全部重新初始化下。我以前看到过一个帖子，说ADC+DMA出现问题，这个建议仅供参考，不负责任的。

主要卡死在两个地方：
1、就是在初始化SD卡的时候，有一个FindSCR()函数中：
while (!(SDIO->STA & (SDIO_FLAG_RXOVERR | SDIO_FLAG_DCRCFAIL | SDIO_FLAG_DTIMEOUT | SDIO_FLAG_DBCKEND | SDIO_FLAG_STBITERR)))
  {
    if (SDIO_GetFlagStatus(SDIO_FLAG_RXDAVL) != RESET)
    {
      *(tempscr + index) = SDIO_ReadData();
      index++;
    }
  }
卡死在这个while循环中，不过这个可以使用index来判断，当大于1时就跳出，不会影响操作。这个姑且算是解决了吧。呵呵。
2、另一个就卡死在SD_ReadBlock()或者SD_WriteBlock()函数的DMA查询那里，比如SD_ReadBlock()中的：
SDIO_ITConfig(SDIO_IT_DCRCFAIL | SDIO_IT_DTIMEOUT | SDIO_IT_DATAEND | SDIO_IT_RXOVERR | SDIO_IT_STBITERR, ENABLE);
    SDIO_DMACmd(ENABLE);
    DMA_RxConfiguration(readbuff, BlockSize);
    while (DMA_GetFlagStatus(DMA2_FLAG_TC4) == RESET)
    {}
这个就不好解决了，呵呵。通过观察SDIO中断标志，可以看出大多时候是出现了SDIO_IT_RXOVERR错误，但是极个别时候是数据正常。
另外，应用程序中是没有循环等待的。
测试程序是使用的官方例程，里面的DMA是每次使用前都重新配置了的。
很谢谢你的关注，呵呵。

另外，我弱弱的问一下，SDIO发送和接受都是硬件操作吧？那我的中断操作应该不会影响SDIO硬件的发送、响应以及数据接收啊。也就是说前面的SDIO初始化配置都是命令发送以及响应，我查看了，命令发送和响应都是硬件一气呵成的，只要命令一旦装载到命令寄存器，硬件就开始运作，直到接收响应并且置标志位，中断在这些操作中是不会起到干扰的。
当我的中断延时加长后，在SDIO还没有正式传数据的时候就开始出现异常了（就是上面的第一个卡死的地方），这个好像是在读取SCR寄存器，用来确认SD卡是否支持4bits模式，但是这里读取的也是SDIO硬件的FIFO寄存器，也是硬件完成接收操作的。也就是说在出现异常前，所有的通信都是硬件完成，中断也只是间隔在每个操作进程之间的，按照常理来想，中断的长短应该不能引起这种异常啊。所以怎么想都想不通。  呵呵   还望指点迷津啊。

还有一个比较重要的信息，好像卡死的基本上都是读数据的时候，包括第一种卡死的那个while其实也是读数据，写数据好像还没有发现卡死过，虽然也有while循环。是不是跟FIFO有关啊？

while (DMA_GetFlagStatus(DMA2_FLAG_TC4) == RESET)
{}
这个就不好解决了，呵呵。通过观察SDIO中断标志，可以看出大多时候是出现了SDIO_IT_RXOVERR错误，

SDIO_IT_RXOVERR这种错误是怎么解决的？
如果出现了这种错误，你所等待的标志位还是正常的吗？
如果出现错误标志位的话，你所等待的标志位没有置位的话，那你就是在一直等。就是死循环了。
等待的时候，还有做出错处理。
是不是这种情况？

你要防止硬件错误，这就是很多程序要做的工作，同时还要做正确的出错处理。

我跟进去看了，之前认为和写数据没有关系是错误的，读写都有可能错误，就是卡在while (DMA_GetFlagStatus(DMA2_FLAG_TC4) == RESET)处，我将中断延时去掉，开启硬件流控后，也会卡死在这里，反而不开流控还没有卡死，真是郁闷。