. w. Q0 o' S8 F5 e2 i" O) X- u
0 k' h6 h2 R1 k: n* J7 N9 G库版本V1.7.2  文件 stm32f4xx_hal_sd.c
* c" o2 o) u4 s: y. g行数 503
代码节选：
  N6 H( K* U. H+ K8 r

1. HAL_StatusTypeDef HAL_SD_ReadBlocks(SD_HandleTypeDef *hsd, uint8_t *pData, uint32_t BlockAdd, uint32_t NumberOfBlocks, uint32_t Timeout)
   . ?2 `9 L' |8 S1 F
2. {
   6 f+ n! [* ?+ O  s0 g
3.   SDIO_DataInitTypeDef config;
   
4.   uint32_t errorstate = HAL_SD_ERROR_NONE;
   ' D" J0 e4 ~+ n+ N, ]" n1 w, S
5.   uint32_t tickstart = HAL_GetTick();
   " u3 |0 v/ e$ i% J4 C* [
6.   uint32_t count = 0U, *tempbuff = (uint32_t *)pData;
   
7. /* ......... */
   ! G+ T* b- k( Z" J0 ?
8. *tempbuff = SDIO_ReadFIFO(hsd->Instance);
   
9. /* ......... */
   
10. }
    9 Y+ D: E  D# v  M& c

复制代码

bug1: 此处pData 为u8 指针 强转 32位 编译后使用STM指令当pData未4字节对齐时将造成非对齐访问异常。
/ G% J% C; d0 g/ {1 D) O, e9 Abug2: 若pData未4字节对齐，使用DMA模式时会强行向低地址进行4字节对齐造成向低地址的内存越界。
+ ?  L6 s$ j7 G# E注：其中图示代码为bug1所出现的bug点，修复建议：检测对齐，发现未对齐时使用一个32位变量进行数据搬运。
8 f# U: D4 E- p0 f- m# m' T, @bug2未进行查找错误点 望ST工程师自行查找。

" L4 M7 |, v2 V另：对于未知的字节流数据进行非数据等长指针的强制类型转换的这种低级错误发生的ST身上令我等非常失望，希望相关人员（大学生临时工）尽快修复
0 x) v' B3 j+ Z) V% q

甩锅三连：别人怎么没问题；是你不会用；真是辣鸡

stm1024 发表于 2018-9-20 08:30
/ b' R' b& N# w( H+ K! H还好不是硬件bug，谈不上世界末日，而且这个锅，真的可以甩给编译器。

. `' H5 x, g9 o, G- x" j7 `4 n4 Z不过作为一个库，也确实应该考虑完 ...

  x. ]; q" {+ M9 v7 ^不关编译器的事情 指针强转是编译器无法预判是否对齐的 所以只能用STM指令去处理

浪花雷雨 发表于 2018-9-19 17:50
9 M7 A" o( [8 z. m" ]认真三连问：是这样的吗？为什么这样？该改吗？

回答三连：是这样的，暴露接口不对，该改

手工置顶

否认三连 ： 就是这么设计的；不是bug；下个版本再优化

认真三连问：是这样的吗？为什么这样？该改吗？

还好不是硬件bug，谈不上世界末日，而且这个锅，真的可以甩给编译器。
/ s% s, Z1 p) B) a8 k
不过作为一个库，也确实应该考虑完善一些。

lymzzyh 发表于 2018-9-19 17:41
0 f1 `! W- ~7 Z, I3 t* ~+ K2 K# q甩锅三连：别人怎么没问题；是你不会用；真是辣鸡

+ [: x0 b, V. J淡定一点，骚年

不用sd卡不就不会触发bug了吗，你真是辣鸡！

zero99 发表于 2018-9-20 08:45
% J9 \" K- j1 ~: U# o9 m4 H淡定一点，骚年

不不不 这是防喷手段 我已经帮喷子 喷过我自己了

pData实际上是R1，将R1的值复制到栈好像没啥问题...

同样遇到, 坑了一个国庆，不修天理难容

uu799 发表于 2018-10-8 14:02
同样遇到, 坑了一个国庆，不修天理难容

; A3 q4 ], o$ H5 m0 u8 i& C到现在都没有FAE现身说法呢

难道丢一个临时工出来背锅都不愿意的吗