这次公布一个HAL库的BUG，关于F4、F7的，版本是目前最新的CUBEF41.18.0和F7的DFP包里的，版本号是2.9.0，应该对应目前最新的CUBEF7库。
! D+ G3 o  z7 X1 f+ l这个BUG是在DFPF7 2.9.0版本发现的。查看了其他系统的HAL代码几乎一致，因此也应该存在BUG。

  G2 a  c& N2 i9 V( ^4 R希望给使用SDIO、SDMMC功能有异常的网友有所帮助。
: K3 b6 T$ x7 a% Y' H, C8 p* h
环境：WIN7 64bit + MDK5.22
4 l" H7 t% h8 A1 Q  F! d硬件：stm32F7 DISCO (F746)
/ g: O2 ?5 |4 H9 O% {( P使用HAL库对TF进行读取操作，
  t* U# K7 d+ Z; a# F. M+ o方式MA
中断函数：直接调用HAL库的处理函数。
& t  X6 ]& r. H6 ~8 A% L0 v
  M* ?2 A* f6 J

  BUG1：没用使用中断读数据时，当FIFO至少有8个字节时，触发SD_Read_IT(),其中的tmp = (uint32_t*)hsd->pRxBuffPtr的指针没初始化，为0

  BUG2：开启DMA后，当执行DMA中断会不明原因出现DTIMEOUT标志置位，将执行if((hsd->Context & SD_CONTEXT_DMA) != RESET)

5 e( a0 h; B% z' `

  if(HAL_DMA_Abort_IT(hsd->hdmarx) != HAL_OK)会对hsd->hdmarx = NULL;造后续DMA无法正常使用，从面导致FIFO数据无法及时读出，

  最终导致FIFO数据超出8个，置位,导致BUG1产生。

; S+ a  H5 [1 |$ E0 e7 e
- K& F3 @) \( ^( B+ [3 Q# ~具体发现问题过程如下：

$ ?& a( c5 _' p! @; Z" d

V1.01  20171227

1.通过Show Caller Code功能查找在开DMA传输SD数据时，偶发进入HardFault_Handler中断的异常，发现以下情况：

1 Z6 J8 V/ z* L, i; z1 `- f

  a.HAL_NVIC_EnableIRQ(SDMMC1_IRQn)开中断后，SDMMC产生的中断调用库函数HAL_SD_IRQHandler。

( R: b( Q$ d  r6 u5 C; N4 e

  b.HAL_SD_IRQHandler函数会判断SDMMC_IT_RXFIFOHF标志位，如有效则执行SD_Read_IT(hsd)。

/ I8 Y7 `1 s/ l% x  y

  c.当传输数据开始时，SDMMC_FIFO数据大于8个时，且有其它错误中断产生时，如超时，进入SDMMC1_IRQn。

. A* a; r3 V0 T& n

  d.进入中断后，执行SD_Read_IT(hsd)，其中的tmp = (uint32_t*)hsd->pRxBuffPtr;（因为代码没有使用IT方式读取数据，所以该指针没有初始化）

  e.hsd->pRxBuffPtr在之前并没有初始化，在调试时发现值为0,在读取数据时就会改写地址为0数据，最终会出现HardFault_Handler。

) l3 \  J/ j! b1 T$ E- e5 j8 [

  f.调试发现，操作过程中会出现两次TIMEOUT中断，随后HFIFO置位，下个超时中断进来后会进入HFIFO处理流程，SD_Read_IT

& w2 v, S  [3 X: ~8 V1 b

  g.自编写SD的中断函数，不对FIFOHF进行判断，出现错误时，只清标志位，关中断，然后退出

2.HAL2.9.0库的SD中断函数有BUG，

1 v% P9 f3 ?0 X, i3 q" J, `

  BUG1：没用使用中断读数据时，当FIFO至少有8个字节时，触发SD_Read_IT(),其中的tmp = (uint32_t*)hsd->pRxBuffPtr的指针没初始化，为0

  BUG2：开启DMA后，当执行DMA中断会不明原因出现DTIMEOUT标志置位，将执行if((hsd->Context & SD_CONTEXT_DMA) != RESET)

! Y0 S2 K. A- k: n# ?5 H

  if(HAL_DMA_Abort_IT(hsd->hdmarx) != HAL_OK)会对hsd->hdmarx = NULL;造后续DMA无法正常使用，从面导致FIFO数据无法及时读出，

- f, S  I: }, z4 O/ X. p

  最终导致FIFO数据超出8个，置位,导致BUG1产生。

zero99 发表于 2018-2-1 09:29
来晚了，感谢支持，已汇总到1月技术原创
4 ^- G( x# V. u" Q( W3 y/ Lhttps://www.stmcu.org.cn/module/forum/thread-614550-1-1.html ...

谢谢支持，稍后再发一个FW_F7_V1.9.0的USB鼠标的小小BUG

上次你发邮件反馈的bug有回复了没？
# b& r/ O' x0 X这个官方提供的SDIO驱动我也在用，不过只简单的用到了DMA中断读，写只是测试了下没发现问题。
+ y( M, Z; u& L9 ^; `我测试比较简单都没注意到你说的这些bug。

creep 发表于 2018-1-11 09:17
# Y8 Y3 W! Z' P$ T8 N: d# R上次你发邮件反馈的bug有回复了没？
这个官方提供的SDIO驱动我也在用，不过只简单的用到了DMA中断读，写只 ...

上次的回复了，确认了第一个是笔误，第二个是代码还有不完善的地方。
这次的这个BUG，可能只对一些TF存在，我用的是1G的TF卡。
1 l" \' y9 t! A* C: D如果产生超时中断就会激这两个BUG，如果不产生超时中断就没事。

ldskendy 发表于 2018-1-11 21:39
$ |3 _' I5 E" W& B  U上次的回复了，确认了第一个是笔误，第二个是代码还有不完善的地方。
这次的这个BUG，可能只对一些TF存在 ...

7 p5 |: j: p) {; k+ E0 ]) a0 t7 g嗯，我测试的是闪迪的16G和Netac的8G的TF卡，目前还没有发现bug。

来晚了，感谢支持，已汇总到1月技术原创
https://www.stmcu.org.cn/module/forum/thread-614550-1-1.html

我现在用的也是stmf7的 hal 库，读写mmc经常出错

最近也用到F7的HAL库，搞了半天发现连写都没法写了，16年那会我拿F4的时候试着还好好的...