Проблема инициализации SD-карты через шину SDIO из-за сбоя CRC
У меня есть специальная плата на базе микроконтроллера ST Microelectronics STM32F103VE, с картой MiniSD, подключенной к шине SDIO микроконтроллера. Электрические соединения были выполнены точно так, как показано на схемах платы STM3210E-EVAL , проверены и перепроверены, так что я твердо уверен, что они правильные. К сожалению, у меня нет этой платы eval, чтобы проверить, является ли то, что я испытываю, аппаратной проблемой, но это не так. Для тестов ниже я m с помощью карты MicroSD Kingston 2 ГБ (модель MBLYG2 / 2 ГБ), купленной совсем недавно (поэтому она должна соответствовать новейшим спецификациям SD-карты) с прилагаемым адаптером MicroSD к MiniSD; еще не тестировал с другими картами.
Я следую упрощенной спецификации физического уровня SD-карты, чтобы понять, что происходит. Код, который я использую, - это пример кода SDIO, который поставляется со стандартной периферийной библиотекой ST Micro для этого микроконтроллера. Он начинается с отправки CMD0 (GO_IDLE_STATE), затем CMD8 (SEND_IF_COND), а затем ACMD41 (SD_SEND_OP_COND), что выполняется путем отправки CMD55 (APP_CMD), за которым следует CMD41. Линия часов работает на частоте 400 кГц, и в рамках моих усилий по отладке я добавил задержку примерно в 100 тактов между CMD0 и CMD8, поскольку я где-то читал, что это было необходимо, по крайней мере, при работе в SPI Режим. За исключением модификаций, упомянутых ниже, код в точности совпадает с кодом примера.
Когда я впервые попытался запустить пример кода, у CMD55 возникла проблема, которая возникла из-за того, что микроконтроллер буферизовал ответ на CMD8, но пример кода не получил ответ CMD8, поэтому при проверке ответа на CMD55 код фактически смотрел на ответ на CMD8 и был этим расстроен. Я исправил эту проблему, сбросив флаг CMDREND на периферийном устройстве SDIO микроконтроллера перед отправкой CMD55, поэтому, когда код проверял ответ на CMD55, он больше не буферизовал ответ CMD8.
Следующая проблема, и та, которую я в настоящее время застрял на том, что в ответе на CMD55 установлен бит 23 поля статуса карты (COM_CRC_ERROR), что указывает на то, что проверка CRC предыдущей команды не удалась согласно спецификации. Хотя микроконтроллер автоматически вычисляет CRC, я подключил к схеме логический анализатор, чтобы убедиться, что он правильный. Я использую веб-приложение (извините, не могу связать, потому что я новый пользователь, но просто Google для "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
Обратите внимание, что я дважды пытался отправить CMD8 перед отправкой CMD55 , но это не имело значения, первый CMD55 всегда возвращает установленный бит 23. Я могу воспроизводить это каждый раз, когда пытаюсь, поэтому не верю, что это проблема с глюками или шумом. Учитывая, что CRC рассчитываются самим микроконтроллером, они выглядят правильно с точки зрения внешнего объекта (логического анализатора) и были проверены на веб-сайте, о котором я упоминал выше, я не вижу, как проверка CRC карты может давать сбой.
Это как-то ожидается? Может быть, мне следует подождать определенное количество тактов между каждой командой (где-то, где я читал, должно быть 8 циклов, и я считаю, что уважаю это)? Могу ли я просто отправить второй CMD55, если первый выйдет из строя, и быть уже в пути, или будут какие-то негативные последствия? Даже если это решит проблему, мне бы очень хотелось узнать, почему не удается выполнить проверку CRC, поскольку я не думаю, что делаю что-то не так.