Любопытный момент: есть две SD карты (Transcend 512 и 256 Mb) на одной написано 80x На другой 45x, как я понимаю скоростные характеристики. Однако в CSD регистре как у первой, так и у второй в поле TRAN_SPEED вижу 25 Mbit/s. Т.е макс. скорости (по чтению) декларируются одинаковые. Вопрос в чём же разница между 80х и 45х?

25Мбит/линию - это скорость интерфейса, и, скорее всего, у всех так написано. А разница между картами 80х и 45х должна выражаться в большей скорости выполнения команд записи и чтения у первых.

Почему при чтении блоков с адресов близких к максимальной ёмкости карты она просто не отвечает, так задумано?

А у меня она вообще не отвечает на комманду чтения сектора.

Как и когда можно подавать комманду чтения блока?
Потому что у меня блок не читается.

Остановился на следующем:
Подал комманду CMD16 с аргументом 1024 (для проверки)
Карточка выдала 0x40 - неверный аргумент
Потом подаю CMD16 c аргументом 512.
Ответ - 0x00, т.е все ок.

Далее подаю комманду CMD17: и все виснет
получаю одни 0xFF, response r1 нету и в помине.
Не говоря уже о признаке начала блока 0xFE.

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