Ага а на следующей странице от этого же автора ответ мне


Перевожу - это неправильная флеш - не соответствующая спецификации SPI !!!
(кстати я с автором полностью в этом согласен - не соответствует спецификации SPI)

Добрый день

Извиняюсь, если не потеме.

Новую не хотел создавать.

Интересует документ "SDA Physical Layer Specification, Version 2.00.pdf" Только полный не Simplified.

В инете нарыл первую версию и Simplified версию 2.00.
Хотелось бы почитать полную версии 2.00

Дайте внешнюю ссылочу плиз.

Спасибо.

Добрый день.

Вот и я добрался до работы с карточками памяти.

И сразу наступил на грабли.

Проблема в следующем.

Я не могу понять как правильно производить запрос команды и получать на него отклик.

По документации должна отсылаться команда без первоначальной посылки FF (но у вас в кости и еще у одного немца в исходниках я обнаружил перед посылкой команды посыл одного байта FF), вот после отправки команды необходимо отослать 1 байт FF. Так как правильно???

У меня две карты MMC и SD. MMC при запросе (при этом я отправляю вконце еще байт FF) отвечает на CMD0 0x03 на команду CMD1 ответчает последовательно (0x03, 0x01, 0x09,0x09 ....... ). Т.е. на CMD1 она остается в idle да еще потом сообщает мне об ошибке CRC в команде (правда я CRC высчитываю для всех команд). Чувствую что неправильно произвожу запросы к карте. Потому как при всех этих же настройках SD карта вообще молчит. Т.е. в ответ всегда FF (смотрел осцом и там постоянно высокий уровень, картачка не перешла в SPI, не поняла команду).

Что я делаю не правильно???

PS запрос для SD 74 бит выхода на режим не спасают, правда и не мешают. Но это и понятно, нужно только для очень старых карт.

Помогите.

Проверьте еще раз эту последовательность:
1.Переход на SPI протокол (инициализация):
- после подачи питания: Fclk<400KHz; синхронизация и сдвиг бита по переднему
нарастающему фронту, пассивный уровень CLK -0;
- не подавая CS=0, оправить по SPI 10 пустых байт;
- подать команду CMD0 и получить отклик 0х01. Bit_7=0 означает, что карта
откликнулась, Bit_0=1 - находится в спячке. Остальные биты пока не важны.
На CMD0 должна откликнуться любая исправная карта.
2.Активизация карты в SPI режиме:
- подать CMD8 с аргументом пит. напряжения и емкости карты. Если в отклике эта команда
допустима (Bit_2=0), то карта ver2.00 и выше и она по напряжению совместима. Далее ее
следует вывести из спячки командой CMD41 и проверить емкость CMD58.
-если отклик R1 на CMD8 неверен, то применить ACMD41. Если карта не выходит из спячки,
то это не SD_карта.
-для MMC_карты применяется команда CMD1.

Сообщение отредактировал Linker - Apr 8 2008, 15:42

Большое спасибо за цитату сообщения от SALOME, но видно я сумбурно объяснил.

Попробую по порядку.

Частота сейчас 200кГц.
74 такта с CS в 1 или 0 я посылал (эффект будет только на старых картах. В новых доках об этом даже слова не упоминается).

А вот теперь самое главное. КАК ПОСЛАТЬ КОМАНДУ?????

Я выставляю на шину 6 байт команды и еще один байт FF при этом карта MMC на 32 метра мне откликается байтом 0x03, MMC+ карта на 1ГБайт откликается 0xFF (т.е. молчит), SD карта на 1Гбайт откликается 0xFF (т.е. молчит). Перекопав различные исходники я обнаружил что народ выставляет 0xFF байт не после передачи команды (хотя в доке указано что нужно после команды, чтения данных или записи данных), а перед этим. Вот это меня повергло в ступор. Я реализую такой запрос (правда не знаю что за этим последует), но хотелось бы внести ясность в этот вопрос. Как (да бог с ним правильно или не правильно) оно вообще работает с SD. Уж на MMC не хотелось бы останавливаться.

Соответственно при использовании SD до последующих запросов (будь то команда CMD8 или CMD1 или CMD58 и ACMD41) дело не доходит. Даже если плюнуть на ответ и отбарабанить все остальное, то карта ни на один из за просов не откликается. На шине MISO стоит логическая 1 (высокий уровень, 3.3 в).

По поводу исправности карт сомневаться неприходится. Все MMC я вытащил из своего телефона (и там они исправно работают), а SD я только что купил и проверил ее в КПК.

Кто использовал карточки, гляньте в свои исходники. Как вы карут в SPI переводите. Интересует SD карта.

Глянуть сюда: http://elm-chan.org/fsw/ff/00index_e.html
Там все разжевано и причесано...

Огромное спасибо за ссылку.

Посылка перед командой байта 0xFF оживила карту (вернее SD стала откликатьясна команды).

Сейчас правда карточка остается в idle режиме и не по команде ACMD41 не по CMD1 из него не выходит.

Последовательность такая

CMD0 -> idle
CMD8 -> idle + illegal_command
CMD58 -> idle + OCR регистр 0x008FF00
repeate:
CMD55 -> idle
ACMD41 -> idle
если idle на ACMD41 то на repeate

В общем из цикла не выходит. Менял CMD55 + ACMD41 на CMD1 и тоже не выходит из цикла. Проверял на MMC+ и на другой SD. Результат один. Значит я накосячил. Просмотрел внимательно пример по ссылке (хорошая весчь), но там реализовано точно так же. Никаких нюансов не заметил. Цикл ждал несколько минут.

Может исходник приложить??

Посоветуйте что-нибудь дельное.

Спасибо

Обсуждение снова пошло по кругу. Цитату я привел, как работающую безупречно . Добавить к этому нечего. Вернитесь на начало обсуждение темы. Там все практически сказано.
То что карты заведомо исправны - это хорошо. Команды отправляются вроде правильно. Не забыли, что с первого раза карта может не откликнуться? Повторите посылку всей команды ( ане просто анализ отклика) 100 раз.
А в своем интерфейсе SPI вы уверены? От него очень многое зависит. Осцилом пользовались? Если можете, то выложте осцилограммы. А исходники Вам под какой проц? На каком языке? Может свою прогу выложите? Это будет проще. Да и схему желательно. Ошибка может оказаться в самом неожиданном месте. Посмотрите на этот пример...
 f.rar ( 32.4 килобайт ) Кол-во скачиваний: 283


Сообщение отредактировал Linker - Apr 9 2008, 15:40

Спасибо за ответ.

Я говорил о приложении своих исходников. Чужих не нужно (итак уже много просмотрел).

Осцом пользовался. Сверял осцилограммы с полученными данными, да и вообще смотрел что на шине творится (что в приемнике то и на шине). Единственное что удивило, так то что после каждого запроса команды на байт 0xFF, где то к концу байта, карта начинает выставлять данные (т.е. 0). Если этот байт посмотреть то получается 0xFE. Вроде как оне валидный. Следующий байт считаем как ответ на команду.

100 раз - это как раз 100 запросов CMD55 и ACMD41 с соответствующими ответами.

Спасибо за отклик. Прикладываю архив с исходником. Там драйвер SPI ну и собственно драйвер работы с картой.

Не понял, о каком "запросе команды"идет речь и что это за байт 0xFF?
Посмотрел Ваши исходники. Что-то много всего. Я полагал, что нужно было расписать инициализацию SPI и команду CMD0. Это не более 10-15 откоментаренных строк. А у Вас просто УЖОС какой-то. На ночь глядя без бутылки не разберешься . Интересно, что за проц такой?

Попробую все объяснить

" запрос команды" - это я так назвал посылку команды в карту (выставление на шину SPI 6 байт команды).

байт 0xFF - это байт Ncr

По документации для SPI режима есть таблица таймингов и графики (в 8 циклах). Полная версия документа SDA Physical Layer v 1.0 (полную версию на 2.0 я не нашел).

Ncs от 0 до прочерка (наверное бесконечность) время перед выставлением команды на шину
Ncr от 1 до 8 циклов. Время после последнего байта команды и до начала выставления картой ответа.
Nec от 0 до максимума (прочерк) время после ответа картой (нужно удерживать CS в 0)


Теперь об исходниках.

Я обнаружил что во многих исходниках первый Ncs байт все же выставляется (во многих даже два). Я этого не делал и SD карта молчала на все мои запросы. Но MMC отвечала. Добавив (я об этом писал ранее) этот байт перед отправкой команды, SD стала откликаться (что и делает сейчас). Причем нет нужды, как в примерах, CS при этом поднимать.

Я попытлся проделать как в примерах и посылать перед выставлением команды на шину два (минимум) байта 0xFF. Это привело к тому, что Ncr пришлось так же увеличить на один. Иначе ответ не вычитывался.

Так как SPI я не собираюсь использовать только для карты, и нет желания стоять в цикле и ждать когда SPI все отбарабанит. Я реализовал все через прерывание и буфер заданий. Соответственно городить циклы по проверке не 0xFF в ответе попросту неудобно. Да и как оказалось ненужно. Карта ответ выставляет всегда после Ncr=1.

MMC карта с этими же настройками нормально отвечает и даже можно прочитать пакет CID. Но вот беда. Я вижу что все данные (и ответы и данные) сдвинуты на один бит влево. Настройка SPI ситуацию не исправила, а даже ухудшила (сдвиг получился на два бита). Ну да с MMC я особо работать и не хочу.

По поводу исходников.

Они не так и сложны как кажутся Коментариев там вагон. Правда порой просто скопированные со строкой.

SD_Card.c
void SD_card_main(void) это основная процедура для вызова в main цикле приложения. Там находятся обработчики всех команд карты. В принципе больше там ничего нет (обработчики команд, обработчики принимаемых данных). Все общение с картойи и других процедур происходит по средством буфера SD_block. SD_block в последствии должен перекочевать из явного массива в работу через указатель. Сама процедура использует три массива SD_status (тут лежат подготовленная команда для отправки, и параметры карты), SD тут лежит текущая отправляемая/нная команда (структура) и response тут лежит ответ (тоже структура) на отправленную команду. По идее SD и response в последствии должны быть одним буфером на который будут накладываться эти структуры. Но это потом.

void SD_detect(void) это процедура для таймера. через определенное время, если карта свободна (никто с ней не работает, ниодна процедура) инициирует процесс опроса карты на предмет присутствия ее. Все действия по инициализации будут выполнены в SD_card_main

SPI.c
bit Spi_WR(byte * dat, byte * complete, word LEN, byte type) производит попытку скопировать данные для отправки в SPI шину в свой буфер и производит запись в журнале заданий SPI о необходимости передачи данных. Если шина свободна, то инициирует передачу.

bit Spi_RD(byte * ptr, byte * complete, word LEN, byte type) делает запись в журнале заданий SPI о необходимости прочитать данные из устройства. Если шина свободна инициирует чтение.

void SPI_inter(void) собственно обработчик прерывания SPI. Производит передачу или прием данных в устройство на SPI шине согласно журналу заданий. Если задания закончились освобождает шину.

SPI_mas - собственно журнал заданий и массив для функции записи данных в SPI.

Все это написано под F120 (это 51 ядро 100 Мгц). На нем реализован алгоритм вычисления некой функции и по этому нет возможности тупо стоять в SPI пока все уйдет или прийдет. Для этого и реализована возможность работы задач SPI отдельно от основных вычислений. В этой системе реализована работа с графичиским LCD экраном, работа с матрицей 8 на 8 кнопок, передача данных по UART, работа с IIC устройствами. На борту 128 килобайт ОЗУ. Для этого включена работа с far памятью. Проц со всем этим нормально справляется. Не стоит говорить про АРМ и что либо другое (сам знаю). Но эту систему я реализовал в полном объеме (кроме карты SD, это не доделал) за 2 месяца.
В будующем пересяду на АРМ, но АРМ9. Ибо АРМ7 мало.

Вроде в кратце описал исходник и свои термины.

Вот в голову пришло. У меня подтяжки висят на свободных ногах SD карты к питанию. Может оставить ноги в воздухе???? Вроде подтяжки мешать не должны.

Сейчас решил перечитать спецификациют от корки до корки.

CRC
http://electronix.ru/forum/index.php?showt...pid=395189&

Спасибо за ссылку. Это не помогло. Карточки не SDHC.

Сегодня походил по офису и насобирал флешь карт.

Вот что получилось.

Набрал:
MMC+ 1Gb
MMC 32mb
MMC 16mb
SD 1Gb 2 штуки разных производителей
microSD 2Gb

Программу не менял. Все как было так и осталось. Настройки SPI не менял.

Выход:
MMC+ 1Gb ни на CMD1 ни на ACMD41 из idle не вышла
MMC 32mb откликнулась нормально, но все данные сдвинуты на один бит влево. Если все сдвинуть на один бит вправо, то по полученным данным видно что карта из idle вышла и даже нормально отдала CID и CSD.
MMC 16mb ни на CMD1 ни на ACMD41 из idle не вышла
обе SD 1Gb ни на CMD1 ни на ACMD41 из idle не вышли

и теперь апофеоз.

microSD 2Gb нормально вышла из idle на ACMD41 и благополучно выдала мне CID и CSD регистры.
По данным CSD_STRUCTURE карта версии 1.0 (да и на CMD8 она ответила illegal command). Длина блока в ней прописана 1024. После уставки в нее длины блока 512, на запрос блока данных карт отдала блок 0xFF (но тут я ещ ене проверял и навернео что-то напортачил).

Главное! SD размером 2Gb (не SDHC) нормально заработала. Я в ступоре.




Сообщение отредактировал AndreyS - Apr 11 2008, 14:30

Добрый день.

Бью себя об стену. Причем жестоко.

Все работает нормально. На плате горе сборщик поставил по питанию SD карты 100 ом резистор. На нем, при включении карты и выходе ее на режим (в зависимости от тока потребления), напряжение падало. Соответственно карта 2Gbyte просто меньше всех кушала и долше всех держалась.


Прошу прощения у всех, что замучал дурацкими вопросами.

Здравствуйте!
Может у кого есть информация по команде CMD8? Пока не понял в аргументе, что писать: нули или величину питающего напряжения(реального). В каком виде? Не подскажет ли кто? Спасибо.