我完全懂你现在的糟心处境——本来指望DMA把SD卡速度提上去，结果第一次读就卡超时，连中断都没触发，这直接把项目进度卡壳了。结合你说的场景（CubeMX配置、无DMA时正常工作），给你梳理几个具体的排查方向，一步步来定位问题：

• 核对NVIC中断优先级与启用状态
  STM32L4的中断优先级分组直接影响中断能否正常响应。打开CubeMX的NVIC配置页，确认SDIO全局中断和对应DMA通道（比如SDIO_RX_DMA）的抢占/子优先级配置合理——DMA中断优先级不能低于SDIO中断，避免被SDIO中断抢占后无法触发。同时一定要确认这两个中断的「Enabled」选项是勾选状态，别漏开了中断开关。

• 验证DMA通道的硬件映射正确性
  STM32L476的SDIO外设和DMA通道是有固定映射的（比如SDIO接收对应DMA2通道4，发送对应DMA2通道5，具体以芯片参考手册为准）。检查CubeMX里SDIO的DMA配置是否选对了通道，要是选错了通道，SDIO的DMA请求根本传不到DMA控制器自然不会触发中断。

• 检查DMA初始化的关键参数
  翻开CubeMX生成的MX_DMA_Init()函数，仔细核对对应DMA通道的配置：

  • DMA_Mode必须设为DMA_NORMAL（SD卡块传输是单次完成，不需要循环模式）
  • DMA_PeripheralInc设为DMA_PINC_DISABLE（SDIO的数据寄存器地址固定，不需要递增）
  • DMA_MemoryInc设为DMA_MINC_ENABLE（内存地址需要逐字节/逐块递增）
    这些参数错一个都可能导致DMA传输异常，进而没中断。

• 降低SDIO时钟频率测试
  启用DMA后，SDIO时钟频率过高可能导致硬件层面的传输同步问题，连DMA请求都发不出来。你可以暂时调大SDIO的时钟分频值（比如把分频从4改成8，降低时钟频率），再测试DMA读操作是否能触发中断。另外也要确认SDIO的时钟源是稳定的（比如用PLLSAI1或者HSI，别选不稳定的时钟源）。

• 用内存到内存DMA测试硬件通路
  写一段极简的测试代码：跳过SDIO外设，直接配置DMA做内存到内存的传输，然后看是否能触发DMA中断。如果这个测试能正常触发中断，说明DMA控制器和NVIC的配置没问题，问题肯定出在SDIO外设和DMA的联动上；如果内存到内存也没中断，那就是DMA或NVIC的基础配置有问题，得从这里入手排查。

• 检查DMA启动后的状态寄存器
  调用HAL_SD_ReadBlocks_DMA()之后，立刻查看hsd->State的状态，确认是不是HAL_SD_STATE_BUSY。同时可以直接查看DMA通道的寄存器HDMA->Instance->CR，确认EN位（DMA使能位）有没有被置1——如果EN位没置1，说明HAL库在启动DMA的时候悄悄出了错误，只是没返回错误码而已。

• 尝试升级HAL库和CubeMX版本
  你怀疑库文件有问题是很合理的，旧版本的STM32 HAL库确实在SDIO DMA处理上存在过bug。可以把CubeMX升级到6.6.0以上的新版本，同时把STM32L4的HAL库更到最新，重新生成代码后再测试，说不定就能解决这个问题。

内容的提问来源于stack exchange，提问作者Marco Morocutti