5

我有一个基于 ST Microelectronics STM32F103VE 微控制器的定制板,MiniSD 卡插入微控制器的 SDIO 总线。电气连接完全按照STM3210E-EVAL 电路板原理图完成,经过反复检查,因此我坚信它们是正确的。不幸的是,我没有评估板来测试我遇到的是否是硬件问题,但似乎并非如此。对于下面的测试,我使用的是最近购买的金士顿 2 GB MicroSD 卡(型号 MBLYG2/2GB)(因此它应该符合最新的 SD 卡规格)和随附的 MicroSD 到 MiniSD 适配器;还没有用任何其他卡测试过。

我正在遵循 SD 卡物理层简化规范来了解发生了什么。我正在使用的代码是 ST Micro 为该微控制器提供的标准外设库附带的示例 SDIO 代码。它首先发送 CMD0 (GO_IDLE_STATE),然后是 CMD8 (SEND_IF_COND),然后是 ACMD41 (SD_SEND_OP_COND),这是通过发送 CMD55 (APP_CMD) 和 CMD41 来完成的。时钟线的时钟频率为 400 kHz,作为调试工作的一部分,我在 CMD0 和 CMD8 之间添加了大约 100 个时钟周期的延迟,因为我在某处读到它是必需的,至少在 SPI 中运行时模式。除了下面提到的修改之外,代码与示例代码完全相同。

当我第一次尝试运行示例代码时,CMD55 出现问题,恰好是因为微控制器正在缓冲对 CMD8 的响应,但是示例代码没有检索到 CMD8 的响应,所以在检查对 CMD55 的响应时,代码是实际上看着对 CMD8 的反应并为此感到不安。我通过在发送 CMD55 之前清除微控制器 SDIO 外设上的 CMDREND 标志解决了这个问题,所以当代码检查对 CMD55 的响应时,它不再缓冲 CMD8 的响应。

下一个问题,也是我目前遇到的问题,是在对 CMD55 的响应中,设置了卡状态字段 (COM_CRC_ERROR) 的第 23 位,这表示根据规范对前一个命令的 CRC 校验失败。虽然微控制器会自动计算 CRC,但我还是在电路上连接了一个逻辑分析仪以验证它是否正确。我正在使用网络应用程序(抱歉,无法链接,因为我是新用户,但只是谷歌的“CRC ghsi”,这是第一个结果)来验证 CRC,使用多项式 x^7 + x^ 3 + 1 根据规范。这是逻辑分析仪的输出,由我格式化和评论:

// uC sends CMD0, CRC OK, no response:
01 000000 00000000000000000000000000000000 1001010 1
// uC sends CMD8, CRC OK, check byte = 0xAA:
01 001000 00000000000000000000000110101010 1000011 1
// SD card responds to CMD8, CRC OK, check byte echoed back = 0xAA:
00 001000 00000000000000000000000110101010 0001001 1
// uC sends CMD55, CRC OK:
01 110111 00000000000000000000000000000000 0110010 1
// SD card responds to CMD55, CRC OK, note card status bits 23, 8 and 5 set;
// bit 23 = COM_CRC_ERROR, bit 8 = READY_FOR_DATA and bit 5 = APP_CMD:
00 110111 00000000100000000000000100100000 0000100 1

另请注意,如果我在上述交换后立即第二次尝试 CMD55,则第 23 位未设置:

// uC sends CMD55, CRC OK:
01 110111 00000000000000000000000000000000 0110010 1
// SD card responds to CMD55, CRC OK, bits 8 and 5 still set but 23 not set:
00 110111 00000000000000000000000100100000 1000001 1

请注意,我在发送 CMD55 之前尝试发送 CMD8 两次,但没有区别,第一个 CMD55 总是返回第 23 位设置。我每次尝试都可以重现这个,所以我不相信这是故障或噪音的问题。考虑到 CRC 是由微控制器本身计算的,从外部实体(逻辑分析仪)来看,它们看起来是正确的,并且已经在我上面提到的网站上进行了验证,我看不出卡的 CRC 校验是如何失败的。

这是以某种方式预期的吗?也许我应该在每个命令之间等待一定数量的时钟周期(我读到的地方应该是 8 个周期,我相信我尊重这一点)?如果第一个失败并且正在路上,我可以只发送第二个 CMD55,还是会产生任何负面后果?即使这样可以解决问题,我也非常想知道为什么 CRC 检查失败,因为我认为我没有做错任何事情。

4

2 回答 2

5

我发现了问题。在我不得不修改代码以刷新 CMD8 响应的缓冲区,以便 CMD55 读取正确的响应之后,我所做的每次测试都将逻辑分析仪连接到电路。移除逻辑分析仪后,代码开始工作——可能它正在向线路注入噪声。不需要延迟,但为了遵循规范,我在 CMD0 之前添加了 74+ 个时钟周期的延迟。

于 2010-11-29T14:43:08.810 回答
0

检查STM 留言板

AFAIK,这些错误已在外围库的最新版本(3.4.0)中得到修复。

于 2010-11-28T18:14:15.467 回答