Jump to content

    
Sign in to follow this  
rain1975

SD Card - програмная реализация интерфейса

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Почему при чтении блоков с адресов близких к максимальной ёмкости карты она просто не отвечает, так задумано?

 

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

Share this post


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

 

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

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

 

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

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

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

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

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

 

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

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

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

:help:

Share this post


Link to post
Share on other sites
Как и когда можно подавать комманду чтения блока?

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

 

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

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

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

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

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

 

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

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

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

:help:

 

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

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


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

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

 

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

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

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

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

 

Спасибо!

:a14:

Share this post


Link to post
Share on other sites
Если я правильно понимаю эта процедура должна у меня возвратить R1,

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

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

 

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

 

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

mmc.zip

Share this post


Link to post
Share on other sites

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

 

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

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

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

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

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

 

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

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

Share this post


Link to post
Share on other sites
Может кто-то поделится информацией насчет следующего.

 

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

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

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

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

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

 

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

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

 

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

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

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

 

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

Share this post


Link to post
Share on other sites
Подозреваю что дело в логической адресации и физической адресации блоков, дело в том что нулевой блок не имеет логического адреса, а соответственно блок с физ.номером 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 за деньги распространяет? а то я его не видел :)

Share this post


Link to post
Share on other sites

Подозреваю что дело в логической адресации и физической адресации блоков, дело в том что нулевой блок не имеет логического адреса, а соответственно блок с физ.номером 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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this