1. Что касается команды CMD16, то BLOCKLEN обычно может быть от 1 до 512, карточки с возможной длиной более 512 не встречал.
2. Команду CMD17 подаётся в состоянии tran, вы правильно подаёте её, т.к вы находитесь в этом состоянии (иначе бы команда и CMD16 не работала). Проблема видимо в получении данных по линии DAT0-3(или DAT0 если 1-битный режим). Убедитесь что работает правильно код получения даныых по линии данных.

Согласен с вами полностью, вот только одного не могу понять:
В принципе, если я достаточно внимательно читал мануал,
то CMD17 должна выдать хотя бы R1,
Использую ту же процедуру вызова что и для CMD16
вот только ответа нет.
Может надо выждать какое-то время, я не знаю...
Я уже даже написал цикл, в котором жду какого-либо
ответа, отличного от 0xFF, но программа зацикливается.

Режим у меня действительно однобитный, точнее SPI.
Инициализацию проводил коммандой CMD1,
хотя советуют ACMD41,
CSD тоже считался:
00 5D 01 32 13 59 80 E3 76 D9 CF FF 16 40 00 4F

Вот кусок кода, который у меня шлет комманду (пока ATMEGA128, далее планирую перевести на ARM, его пока только изучаю)

unsigned char MMCCommand(unsigned char command, unsigned long adress)
{
SPI_WRITE(0xFF); //Dummy write
SPI_WAIT();
SPI_WRITE(command);
SPI_WAIT();
SPI_WRITE((unsigned char)(adress>>24)); //MSB of adress
SPI_WAIT();
SPI_WRITE((unsigned char)(adress>>16));
SPI_WAIT();
SPI_WRITE((unsigned char)(adress>>8));
SPI_WAIT();
SPI_WRITE((unsigned char)adress); //LSB of adress
SPI_WAIT();
SPI_WRITE(0xFF); //dummy checksum
SPI_WAIT();
SPI_WRITE(0xFF); //16 bit response
SPI_WAIT();
SPI_WRITE(0xFF);
SPI_WAIT();
}
return SPDR.

Если я правильно понимаю эта процедура должна у меня возвратить R1,
и возвращает на комманды CMD1, CMD9, CMD16.
(для CMD0 не подходит, там надо CRC 0x95).

Что ж такого особенного у комманды CMD17 что она не выдает ответ R1?

Такой же ответ, тоесть никакого (0xFF), я получал от карточки на комманду
CMD17, когда забыл CHIP SELECT подать, но уже исправил.

P.S. Я конечно не исключаю ошибок в своем коде, но может дело
в чем-то другом, о чем я даже не догадываюсь?
может есть какие-то особенности с коммандой чтения блока?

Как я понимаю вы пытаетесь работать в SPI режиме (я работал тольков SD-режиме). Судя по описания процедура инициализации SPI-режима должна начинатся так: командой CMD0 с активным CS (в нуле), далее идёт CMD1 и.т.д.
Может карта осталась в SD-режиме.

Вы все-таки были правы, в моем коде была ошибка, пока правда не знаю в чем именно
(разберусь-напишу), потому что переписал заново с нуля участок программы чтения сектора.
Уже получил ответ R1.
Пойду дописывать код.

Спасибо!

Вот кусок кода который у меня работает на AVR и ARM.

Может кто-то поделится информацией насчет следующего.

Считал блок с SD-карты, но почему-то нулевой блок на самом деле оказался не нулевым.
WinHex показал совсем другой результат.
Короче в ВинГексе я не нашел того блока который считал контроллером.
Хотя когда считал блок под номером 10000 (карточка у меня на 16 Мб),
то он полностью совпал с тем что выдал WinHex (номер не смотрел).

Думается, что задав начальный адрес 0, я попал в зашифрованную область карты
(такая вроде бы сущетвует,если я не ошибаюсь). Или нет?

Подозреваю что дело в логической адресации и физической адресации блоков, дело в том что нулевой блок не имеет логического адреса, а соответственно блок с физ.номером 1 имеет логический адрес 0. Видимо WinHex (и другие программы) через Win-ды видят логическое пространство.
Соответственно считав с карты блок с адреса 512, видимо в WinHex'e он будет по нулевому адресу, проверьте интересно.
А физический нулевой блок это просто бутовый блок (см. FILE SYSTEM SPECIFICATION).

Кстати с нулевым блоком связаны интересные моменты, если его стереть (или испортить) то Wind'ы не смогут отформатировать карту, вот так вот они сделаны.

Да, примерно так оно и получилось. Только немного смущает что у 16Мб карточки оказалось 57 скрытых секторов, а в 32Мб - вообще нету скрытых.
В 16Мб карточке первый отображаемый в WinHex сектор:
Physical sector No:57
Logical sector No:0

Для 32Мб - просто выдает номер сектора, не говорит логический это или физический.
Непонятно почему в одной карточке есть эти скрытые сектора, а в другой - нет.
Форматирование ничего не поменяло. Может надо что-то типа lowformat, чтобы убрать невидимые сектора, или это невозможно?

А что это за документ такой FILE SYSTEM SPECIFICATION? Это случайно не тот, который Sandisk за деньги распространяет? а то я его не видел

По этой ссылочке есть хороший пример файловой системы и чтение с ММС в multisector режиме
http://elm-chan.org/fsw/ff/00index_e.html

А что бы Вы посоветовали в случае EP9302? Если я правильно понял, то SD-card к нему можно только по SPI подключить, а хотелось бы по протоколу SD работать, но не реализовывать это все программно.

Что в вашем понимании "реализация протокола"?
Если прием и передача команд по SD-протоколу - то програмная реализация займет строк 30-40.

В случае EP9302 я бы вообще не советовал связываться с SD: по SPI получается медленно, а преимуществ программной реализации SD-протокола через GPIO я, честно говоря, не вижу.
Впрочем, про эмуляцию SD лучше спросить у Andrei.....

Еще можно:
- поставить внешний контроллер
- подключить карту через USB адаптер
- сделать свой контроллер на программируемой логике

На практике годится только третий вариант: stand-alone контроллеры SD почти не встречаются, а при подключении через USB выйгрыш по скорости будет совсем небольшим по сравнению с SPI.


Пять сотен строк минимум.

Спасибо.

Не могли бы вы поделиться ссылками на какие-нить процессоры, где реализован SD-контроллер. Просто чтоб почитать, что он из себя представляет. Что-то не могу найти ничего.

ps: у меня есть опасение, что я не смогу воспользоваться готовыми вещами в WinCE 5.0 (в плане работы с картами SD), если буду подключать карточку по SPI.

Это полная реализация протокола.
Я имел в виду "прием байта", "передача байта".

Можно посмотреть AT91SAM9261, но описание там довольно куцее, еще Sharp, Samsung и т.д.
Но лучше почитать полную спецификацию SD, она есть на FTP.


Вполне справедливое опасение: в WinCE BSP для ep93xx ничего подобного нет. Да и под Linux придется писать свое.

Подскажите, плз.
EP9302 работа с SD-card в SPI-mode.

CMD0 выполняется правильно - получаю 0х01.

Далее, что надо для работы SD-card в SPI-режиме?

А то в исходниках EFSL далее идет CMD1, а Тошибовском мануале, например, сказано, что DO NOT USE CMD1, а юзайте ACMD41.

Почитайте даташит на микроконтроллер LPC2378, в нем есть контроллер SDIO (в даташите называется MCI), там описаны принципы действия и архитектура вдух автоматов-данных и команд. Аналогично можно это все реализовать и на ПЛИС

А ещё есть AT32AP7000 (ядро AVR32), для которого (в том числе) есть Linux, который можно грузить как раз (и опять же в том числе) с SD-карты, поддерживаемой аппаратным модулем Multimedia Card Interface.
Сам не сравнивал, но думаю, что этот модуль аналогичен тому, что в ARM9-процессоре от Atmel.
Про портирование WinCE на платформу AVR32 ничего не слышал.

P.S. А ветки по AVR32 всё нет

Спасибо.

Вот тут возник вопрос по EP9302. Какие значения надо записывать в биты SPO и SPH в регистре SSPCR0 в SSP? Имеется ввиду работа с SD-card по SPI.

SPI у EP93xx адекватно ведет себя только в режиме SPO=0, SPH=0, но это касается генерации сигнала SFRMOUT. Если он не используется, то для работы с картой можно использовать и режим SPO=1, SPH=1.

Спасибо.

Вот что-то не могу найти в документации: при подаче ACMD41 (т.е. CMD55 + CMD41), какой ответ я должен ожидать от CMD55? 0x01?

По-идее, 0x01. В SPI режиме не обязательно использовать ACMD41, можно использовать CMD1.

Зависит от предыдущего состояния, посему в общем случае ожидайте любой меньший или равный 0x01 - это наиболее правильная реализация.




Если эта команда, не используется для распознавания MMC/SD, однако.

Изввиняюсь, сразу не сказал. Подразумевается, что я подавал уже CMD0 и добился ответа 0х01. Карточка только SD.

Мня. Ступил, однако

При помощи CMD1 карточка (microSD 1024 Mb Kingston ) активизировалась в SPI-режиме, т.е. я получил R1 == 0x00. Теперь попытался получить CSD. т.е. CMD9 с аргументом == 0. Последний байт с CRC7 выставляю в 0xFF. Вся команда: 0x49, 0x00,0x00, 0x00, 0x00, 0xFF.

В ответ получаю
- R1 == 0x00
- признак начала данных - 0xFE
- 16 байт

Если еще попинговать карту FF-ми, то получаем еще 1 байт.

Странно, вроде, по идее, я должен получить 16 байт данных после 0xFE и CRC16, т.е. еще 2 байта.

Что-то я не так сделал, но вот что?

Это как?


А CRC включен (CMD59)?

CRC = 0x00, у меня.

Точнее любое значение без старшего бита в течении не более 80 тактов

сканируя в течении не более 100ms

Да.

Ну получаете, то сколько угодно байт, но они все кроме первого 0xFF? Ну А может CRC 0xXXFF
Не знаю, я в мусорник два байта вычитываю и все.

Да.

Ну отправляю 0xFF и жду, придет лии что нить еще, не равное 0xFF.



CRC не включен. В мануале написано, что в SPI он по умолчанию отключен, но я так понимаю, что эти байты(CRC16) все равно присылаются, но их надо игнорировать. Или я неправ?

Сейчас слегка переделал прием, чтобы только непрерывные последовательности байтов != FF принимать.
Получается, после 0xFE принимается сначала 10 байт, не равных FF, затем сколько-то 0xFF и затем следующая последовательнеость - 7 байт не равных 0xFF. И все. Как-то непонятно. Вроде данные с CRC16 должны идти непрерывным массивом.

Присылаются, только стандарт не оговаривает, что в них передается.


Данные всегда идут непрерывным массивом после токена, принимать нужно все.

Присылаются, только стандарт не оговаривает, что в них передается.

Ессно.

Короче, это я лось педальный. У меня ФФ-ы выкидывались, а один из них был в массиве CSD.

Все нормально карточка отвечает теперь(00 + FE + 16 байт CSD + 2 CRC16) и даже осмысленные данные в CSD.

Насчет CSD->C_SIZE, я так понял, что значения этого поля зависят от производителя? В мануале тошибы - одни значения, у SanDisk - другие. Мне Kingston возвращает третьи. А вот у 16Mb Sd card Canon - совпадает с мануалом от SanDisk.

Подскажите, люди добрые, что я не так делаю.
Прошерстил все источники, просмотрел все исходники, написал прожку.

Настройка портов:

#define SPI_NPCS1_CONFIG (/*255<<24|0xFF<<16|*/AT91C_SPI_NCPHA|AT91C_SPI_BITS_8|(120<<8)) //400 kHz

AT91F_PMC_EnablePeriphClock ( AT91C_BASE_PMC, 1 << AT91C_ID_PIOA ) ;

AT91C_BASE_PIOA->PIO_PER = AT91C_PIO_PA25 | AT91C_PIO_PA23; // DispRS and DispReset
AT91C_BASE_PIOA->PIO_OER = AT91C_PIO_PA25 | AT91C_PIO_PA23;
AT91C_BASE_PIOA->PIO_SODR = AT91C_PIO_PA25 | AT91C_PIO_PA23;

// ======== Init SPI ================
AT91PS_SPI pSPI = AT91C_BASE_SPI ;
AT91F_SPI_CfgPMC(); // Enables the SPI Clock
AT91F_SPI_CfgPIO(); // Open PIO for SPI
AT91F_SPI_Reset(pSPI);// Reset SPI
AT91F_SPI_CfgMode(pSPI, SPI_MODE); // Configure SPI in Master Mode with No CS selected
AT91F_SPI_CfgCs(pSPI, 0, SPI_NPCS0_CONFIG); // Configure SPI0 Display CX65

pSPI->SPI_CSR[1] = SPI_NPCS1_CONFIG;
pSPI->SPI_IDR = 0xffffffff; //отключение прерываний

AT91F_SPI_Enable(pSPI); // SPI_Enable

AT91F_PIO_CfgInput(AT91C_BASE_PIOA, CARD_PROT|CARD_DET);

AT91C_BASE_PIOA->PIO_PER = AT91C_PIO_PA9; // CS1 for MMC/SDC
AT91C_BASE_PIOA->PIO_OER = AT91C_PIO_PA9;
AT91C_BASE_PIOA->PIO_SODR = AT91C_PIO_PA9;

Передача/прием байта:
void xmit_spi(char dat)
{
while (AT91C_BASE_SPI->SPI_SR & AT91C_SPI_TDRE==0);
AT91F_SPI_PutChar (AT91C_BASE_SPI, dat, 1);
}


static
BYTE rcvr_spi (char dat)
{
char res;
while (AT91C_BASE_SPI->SPI_SR & AT91C_SPI_TDRE==0);
AT91F_SPI_PutChar (AT91C_BASE_SPI, dat, 1);
while (AT91C_BASE_SPI->SPI_SR & AT91C_SPI_RDRF==0);
res = (BYTE)( AT91C_BASE_SPI->SPI_RDR );

return res;
}


Работа с картой:
do
{
__disable_interrupt();
DESELECT(); // поднять CS
Delay_mks(100);
for (n = 10; n; n--) xmit_spi(0xFF); /* 80 dummy clocks */
n=0;
ty=0;
SELECT(); // опустить CS
Delay_mks(100);

xmit_spi(0x40);
Delay_mks(100);
xmit_spi(0);
Delay_mks(100);
xmit_spi(0);
Delay_mks(100);
xmit_spi(0);
Delay_mks(100);
xmit_spi(0);
Delay_mks(100);

cmd=rcvr_spi(0x95);
// Delay_mks(100);
n=255;
while (cmd == 0xFF && n)
{
n--;
cmd = rcvr_spi(0xFF);
}
} while (cmd == 0xFF);

DESELECT();


Сначала ваще ничего не получал в ответ (0xFF), потом поставил ожидание после каждой SPI посылки 100 мкс, начал получать 0x01 в ответ на CMD0 (для MMC карты, и 0x05 для SD). Если изменял время задержек мог получать всяку ерунду, типа сдвинутого ответа.
Если убрать хоть одну задержку - ответ 0xFF, т.е. нет ответа.
Пробовал ставить аппаратные задержки в SPI #define SPI_NPCS1_CONFIG (255<<24|0xFF<<16|AT91C_SPI_NCPHA|AT91C_SPI_BITS_8|(120<<8)) - нет ответа.
MMC Canon 16MB
microSD SanDisk 512MB
SAM7S64

ЗЫ Дисплей от S65 на SPI0 - работает отлично.

Посылку и прием лучше сделать одной универсальной функцией. Ждать по while (AT91C_BASE_SPI->SPI_SR & AT91C_SPI_RDRF==0); и всегда вычитывать AT91C_BASE_SPI->SPI_RDR.

делал,
без разницы (собственно, как и предполагалось)
во многих примерах чтение и запись сделаны раздельно, наверно что бы немножко экономить время

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

Тогда по пунктам. Если после отправки не дождаться принятия байта, то он конда-нибудь все же примется. тем самым взведет соответствующий бит в статус-регистре. При следующей посылке с чтением вы посылаете байт и тут же проверяете флаг принятия байта. Но он остался взеведенным с прошлой посылки. При этом контроллер именно в этот момент принимает байт. Что вы в этот момент прочитаете из регистра принятых данных - х.з. Хорошо если предыдуший принятый байт. Соответственно с задержками это все будет как-то работать.
Если уж так хочется иметь две разные функции, то перед отправкой делайте пустое чтение регистра принятых данных. тем самым сбросите флаг и дождетесь действительного нужного вам байта.

Здравствуйте!!! Подскажите с инициализацией micro SD Apacer 1024Mb. Работаю через LPT. CMD и DAT подтянуты к питанию через 30к. Шлю CMD=0, ответ =1. CMD=1, ответ=255 и все, никание команды не принимает. При CMD=55 + CMD=41, эффект тот же. Если после CMD=0 ввести CMD=58 Ответ: 0 255 128 255. Ответ на CMD=8 ответ=9. Как ввести этой команде атрибуты нигде не нашел. А она вроде участвует в инициализации. Спасибо.

Вообще логично, согласен. Уже сделал на одной функции.
Инициализацию прошел, но с задержками. MMC: CMD0, CMD1, CMD16, дальше пока не пробовал.
Но, откуда задержки? Ни в одном примере их нет, и у всех все работает. Сдираю пример "в ноль" для моего проца - без задержек не работает, уменьшаю задержку со 100 до 50 мкс - не работает.
Есть у кого какие мысли по этому поводу?



С командой CMD8 есть пример сдесь http://elm-chan.org/fsw/ff/ffsample.zip
if (send_cmd(CMD8, 0x1AA) == 1) { /* SDHC */
Я так понял это команда для SDHC карт.

Кристал селект ручками попробуйте дергать. У САМов были проблеммы с автоматическим дерганьем. Кристал селект не успевал уйти в ноль между посылками.

Да он и так ручками дергается. Просто товарищ Вашему совету про оверраны и сброс приемника напрасно совершенно не внял.

CS дергаю вручную
DESELECT();
Delay_mks (100);
SELECT();
Delay_mks (100);
Если и в этом месте убрать хоть одну задержку - команда не проходит.

Очень даже внял. Я же сказал "уже сделал".
Расшифруйте понятие оверран в данном контексте, пожалуйста.

Тогда выложите получившийся вариант. И желательно без загадок типа "SPI_MODE".

Кароче есть ещё офигенная фича: скорость инициализации карточки по SPI не более 200кГерц(у меня на 200 уже не пахало). Если сразу, после подачи питания, пихать данные карточке со скоростью 20МГц, она ничерта не принимает. Больше со своей стороны глюков не видел.В EFSL есть исходник для работы на атмеге.Заменить передачу/приём байтов на свой и усё как по маслу.

Такого ограничения нет. В режиме инициализации скорость должна быть не более 400kHz, но только для обеспечения совместимости с MMC, картам SD все равно.

Вощем добил работу с картой. Испытал создание директории, создание файла, запись в файл.
Все работает только с задержками.
Скорость инициализации ставил от 188 до 400 кГц - все равно требует задержки.
Token отлавливаю софтовым SPI, как рекомендовал QuickWitted (http://www.swordgreenline.narod.ru/BookReader.html), иначе все 3 мои карточки не отвечают нормально.
Использовал FatFs. Интерфейс карты портирован с EFSL.

Проц - SAM7S64
Плата - самопал
Карты - MMC Canon 16 MB, microSD SanDisk 512MB, SDHC Transdent 2MB
Дисплей - LS020 от Siemens S65
IDE - IAR 5.2

Проект сырой. Работает только в конфигурации Debug_Flash (еще не разобрался с ремапами). За стиль не ругайтесь сильно, это мой 2-ой проект.

Если, уважаемый aaarrr, посмотрите, буду весьма признателен.
Нажмите для просмотра прикрепленного файла

Не может такого быть, я на SD как раз и пробовал, может какая старая была, ещё на 32 метра. Ставлю передачу больше 200 кГц и не инициализируется. Зато если инит на 150кГц, а уже потом 20МГц то всё ок.

В спецификации есть вполне конкретная цифра - 400kHz. И примечание, что сделано это для совместимости с MMC.

А у Вас дело, по всей видимости, в чем-то другом.

Хотя просили и не меня... Посмотрел. У вас функция xmit_spi() оставляет после себя невычитаные данные. Если уж так хочется посылать и не ждать приема (хотя ждать там не долго) перепишите функцию отправки с приемом как-нибудь так

Т.е. проверяйте, не осталось ли с прошлой посылки что-то непрочитанное.