[rain1975 0]

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

[aaarrr 63]

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

[rain1975 0]

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

[Fortune 0]

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

 

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

[Fortune 0]

У кого нибудь есть примеры реализации взаимодействия с SD Card? Хотелось бы взглянуть.

 

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

Потому что у меня блок не читается.

 

Остановился на следующем:

Подал комманду CMD16 с аргументом 1024 (для проверки)

Карточка выдала 0x40 - неверный аргумент

Потом подаю CMD16 c аргументом 512.

Ответ - 0x00, т.е все ок.

 

Далее подаю комманду CMD17: и все виснет

получаю одни 0xFF, response r1 нету и в помине.

Не говоря уже о признаке начала блока 0xFE.

[rain1975 0]

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

Потому что у меня блок не читается.

 

Остановился на следующем:

Подал комманду 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-битный режим). Убедитесь что работает правильно код получения даныых по линии данных.

[Fortune 0]

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. Я конечно не исключаю ошибок в своем коде, но может дело

в чем-то другом, о чем я даже не догадываюсь?

может есть какие-то особенности с коммандой чтения блока?

[rain1975 0]

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

Может карта осталась в SD-режиме.

[Fortune 0]

1. Что касается команды CMD16, то BLOCKLEN обычно может быть от 1 до 512, карточки с возможной длиной более 512 не встречал.

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

 

Вы все-таки были правы, в моем коде была ошибка, пока правда не знаю в чем именно

(разберусь-напишу), потому что переписал заново с нуля участок программы чтения сектора.

Уже получил ответ R1.

Пойду дописывать код.

 

Спасибо!

:a14:

[AlexBoy 0]

Если я правильно понимаю эта процедура должна у меня возвратить R1,

и возвращает на комманды CMD1, CMD9, CMD16.

(для CMD0 не подходит, там надо CRC 0x95).

 

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

 

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

mmc.zip

[Fortune 0]

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

 

:a14:

[Fortune 0]

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

 

Считал блок с SD-карты, но почему-то нулевой блок на самом деле оказался не нулевым.

WinHex показал совсем другой результат.

Короче в ВинГексе я не нашел того блока который считал контроллером.

Хотя когда считал блок под номером 10000 (карточка у меня на 16 Мб),

то он полностью совпал с тем что выдал WinHex (номер не смотрел).

 

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

(такая вроде бы сущетвует,если я не ошибаюсь). Или нет?

[rain1975 0]

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

 

Считал блок с SD-карты, но почему-то нулевой блок на самом деле оказался не нулевым.

WinHex показал совсем другой результат.

Короче в ВинГексе я не нашел того блока который считал контроллером.

Хотя когда считал блок под номером 10000 (карточка у меня на 16 Мб),

то он полностью совпал с тем что выдал WinHex (номер не смотрел).

 

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

(такая вроде бы сущетвует,если я не ошибаюсь). Или нет?

 

Подозреваю что дело в логической адресации и физической адресации блоков, дело в том что нулевой блок не имеет логического адреса, а соответственно блок с физ.номером 1 имеет логический адрес 0. Видимо WinHex (и другие программы) через Win-ды видят логическое пространство.

Соответственно считав с карты блок с адреса 512, видимо в WinHex'e он будет по нулевому адресу, проверьте интересно.

А физический нулевой блок это просто бутовый блок (см. FILE SYSTEM SPECIFICATION).

 

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

[Fortune 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 за деньги распространяет? а то я его не видел :)

[AlexBoy 0]

Подозреваю что дело в логической адресации и физической адресации блоков, дело в том что нулевой блок не имеет логического адреса, а соответственно блок с физ.номером 1 имеет логический адрес 0. Видимо WinHex (и другие программы) через Win-ды видят логическое пространство.

Соответственно считав с карты блок с адреса 512, видимо в WinHex'e он будет по нулевому адресу, проверьте интересно.

А физический нулевой блок это просто бутовый блок (см. FILE SYSTEM SPECIFICATION).

 

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

 

 

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

 

По этой ссылочке есть хороший пример файловой системы и чтение с ММС в multisector режиме

http://elm-chan.org/fsw/ff/00index_e.html