embedded - 由于 CRC 失败，SD 卡通过 SDIO 总线初始化问题

Question

我有一个基于 ST Microelectronics STM32F103VE 微 Controller 的定制板，MiniSD 卡插入微 Controller 的 SDIO 总线。电气连接与 STM3210E-EVAL board schematics 中的完全一样。 ，检查和重新检查，所以我有很强的信心他们是正确的。不幸的是，我没有评估板来测试我遇到的是否是硬件问题，但似乎并非如此。对于下面的测试，我使用的是最近购买的金士顿 2 GB MicroSD 卡(型号 MBLYG2/2GB)(因此它应该符合最新的 SD 卡规范)和随附的 MicroSD 到 MiniSD 适配器；还没有用任何其他卡测试过。

我正在遵循 SD 卡物理层简化规范来了解发生了什么。我正在使用的代码是 ST Micro 为该微 Controller 提供的标准外设库附带的示例 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 出现问题，恰好是因为微 Controller 正在缓冲对 CMD8 的响应，但是示例代码没有检索到 CMD8 的响应，所以在检查对 CMD55 的响应时，代码是实际上看着对 CMD8 的 react 并为此感到不安。我通过在发送 CMD55 之前清除微 Controller SDIO 外设上的 CMDREND 标志解决了这个问题，所以当代码检查对 CMD55 的响应时，它不再缓冲 CMD8 的响应。

下一个问题，也是我目前遇到的问题，是在对 CMD55 的响应中，设置了卡状态字段 (COM_CRC_ERROR) 的第 23 位，这表明根据规范对前一个命令的 CRC 校验失败。虽然微 Controller 会自动计算 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 是由微 Controller 本身计算的，从外部实体(逻辑分析仪)来看，它们看起来是正确的，并且已经在我上面提到的网站上进行了验证，我看不出卡的 CRC 校验是如何失败的。

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

Answer 1

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