SDC: ответ на CMD8 не корректен Опции

[Arlleex]

Доброго времени суток. Работаю с микроконтроллером AT91SAM7X512 и SD картой памяти малого объема (2Гб).
При передаче команды CMD0 принимают ответ 0х01, как и положено.
Далее - по блок-схеме из спецификации на SD карту памяти, передаю команду CMD8 и получаю ответ (первый байт является байтом ответа R1) 0хС1, хотя должен получить так же 0х01.
Соответственно, данная ситуация выбила дальнейшую инициализацию SD карты из колеи.
Почему карта первым байтом ответа R7 (коим по идее должен быть ответ R1) является байт, значение которого равно 0хС1?

[aaarrr]

Почему карта первым байтом ответа R7 (коим по идее должен быть ответ R1) является байт, значение которого равно 0хС1?

Тут возможны варианты:
- Вы просто не дожидаетесь ответа на CMD8 (0xC1 надо проигнорировать и ждать дальше нулевого значения в седьмом бите)
- Карта не поддерживает CMD8. У разных карт реакция разная - некоторые просто игнорируют CMD8, другие отвечают "illegal command" и т.п.

[Arlleex]

Опрос ответа на команду со стороны ведущего устройства организовал верно.
А что получается - заменить SD карту памяти на другую?

[aaarrr]

А что получается - заменить SD карту памяти на другую?

Зачем же? Считать, что карта не поддерживает версию 2.0, и работать с ней как с 1.01.

[Arlleex]

Но ведь она не шлет ответ R7 как таковой.
Она шлет что-то типа R7, только вместо первого байта у нее в старшей тетраде не то, что предполагает ответ R1 - значение, старший бит которого равен 0.
Например, 00000001 - хороший ответ, 00000101 - значение, соответствующее указателю на нелегальную команду. А у меня значение 11000001 - старшие биты в старшей тетрады не с 0 начинаются.
А если как ты говорил выше, искать первый бит, равный 0 - у нас происходит тогда "сдвиг" принимаемых данных - мы будем посылать значение - и в ответ приходить будет не то, что надо.
Следовательно, как делаю я:
1) Отправил CMD0
2) Принял ответ R1, равный 0х01 (как и надо)
3) Отправил CMD8
4) Шлю значение 0xFF, пока не получу ответ, отличающийся от 0xFF, затем этот ответ шлю в USART - и смотрю на компе.
5) принимаю остальные байты ответа R7.

Может задержку какую-нибудь делать между CMD0 и CMD8?

[aaarrr]

Может задержку какую-нибудь делать между CMD0 и CMD8?

Каких-либо специальных задержек там не нужно. Искать в ответе байт, отличный от 0xFF, неправильно. Если в течение восьми передач нуля в седьмом бите не последовало, значит нет ответа на команду.

Можете написать, что передается в CMD8 и что возвращается в ответ (скажем, просто 16 байт после команды)?

[Arlleex]

Это программа, которая передает команду CMD8 [0x48 00 00 01 AA 87] SD карте памяти.
Как видно, первый байт, пришедший в USART, равен 0xFF, это значение на линии MISO после отправки последнего байта команды CMD8.
// Передача команды CMD8
SPI_Enable(AT91C_BASE_SPI0); // Включение SPI0
SPI_Write(AT91C_BASE_SPI0, 1, 0x48); // Запись первого байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0x00); // Запись второго байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0x00); // Запись третьего байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0x01); // Запись четвертого байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0xAA); // Запись пятого байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0x87); // Запись шестого(последнего) байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF

USART_Write(AT91C_BASE_US0, response, 0);
for(a=0; a<16; ++a)
{
SPI_Write(AT91C_BASE_SPI0, 1, 0xFF); // Сдвиг "1" на линию данных
response=SPI_Read(AT91C_BASE_SPI0); // Чтение данных
USART_Write(AT91C_BASE_US0, response, 0);
}
SPI_Disable(AT91C_BASE_SPI0); // Отключение SPI
Итак, что приходит по USART:
FF FF C1 7F FF FF FF FF FF FF FF FF FF FF FF FF FF
Вот все что приходит после передачи команды CMD8.
Итак первый байт - 0xFF - Это после передачи последнего байта 0x87 команды CMD8.
Байты [2...17] в вышеприведенных сведениях - это все, что принимает SPI при отправке 0xFF SD карте памяти (ведь ответ нужно ожидать, удерживая линию MOSI в высоком логическом уровне, т.е. передавать 0xFF).
Похоже, ответ R7 (первый байт которого определяется ответом R1) таков:
C1 7F FF FF FF
Но это ни в какие рамки не вписывается.

[aaarrr]

Похоже, ответ R7 (первый байт которого определяется ответом R1) таков:
C1 7F FF FF FF
Но это ни в какие рамки не вписывается.

Хм, если C17F сдвинуть на пару бит влево, то получится ответ "illegal command".

[Arlleex]

Ну да, получается так. Но, ведь как так получается, ведь и ответы и сами команды являются байт-ориентированными, т.е. четко разграничиваются сигналом CS.
А если сдвигать байты влево - это получится, что уже время NCR не кратно байту.
Кстати, насчет того, как проверять ответы.
На многих сайтах сделано именно так - опрашивать линию MISO до тех пор, пока не придет ответ, отличный от 0xFF - и в зависимости от него решать, что делать.
Да и время NCR - оно всегда кратно байту, не может в байте ответа содержаться биты предыдущего принятого байта... Ведь это перекосяк какой-то получается.
В данном случае на 2 бита ответ сдвинулся, а другую команду передам - вообще гадость будет - и гадай тут, на сколько бит что сдвигать, чтобы что-то внятное получилось.
Допустим, нужно проверять ответ - пока не встретится "0" в старшем бите принятого байта.
Но маркеры ответов на данные имеют другой формат, например - 11111110 или 11111100, тут уже никак не угадаешь, на сколько что куда сдвигать.
А о маркерах ошибки вообще молчу - там значения приходят такие:
ххх0data1
- тут о проверке первого принятого бита забыть можно, его значение может быть любым...
Странное поведение SD...
Вроде бы все по байтам четко должно быть разграничено.

Сообщение отредактировал Arlleex - Nov 14 2011, 17:24

[aaarrr]

На многих сайтах сделано именно так - опрашивать линию MISO до тех пор, пока не придет ответ, отличный от 0xFF - и в зависимости от него решать, что делать.

Я не видел еще ни одной приличной реализации работы SD-SPI на просторах интернета.
У R1, 2, 3 и т.п. есть вполне четкий отличительный признак: "0" в старшем бите. Если искать "не 0xFF", работать в большинстве случаев будет. Но не будет соответствовать спецификации.

Вроде бы все по байтам четко должно быть разграничено.

Оно и разграничено на самом деле. Я это к тому, не проскакивает ли в вашей системе на SCK чего лишнего?

[DmitryM]

Я бы предположил еще что nCS успевает вернуться в неактивное состояние. Лучше бы SPI_WriteBuffer или не пользоваться либами, а написать самому.

[Arlleex]

Я не видел еще ни одной приличной реализации работы SD-SPI на просторах интернета.
У R1, 2, 3 и т.п. есть вполне четкий отличительный признак: "0" в старшем бите. Если искать "не 0xFF", работать в большинстве случаев будет. Но не будет соответствовать спецификации.


Оно и разграничено на самом деле. Я это к тому, не проскакивает ли в вашей системе на SCK чего лишнего?

Для ответов на команды - это хороший отличительный знак, что старшие биты всегда имеют значение "0".
Но есть и ответы на данные, маркеры ошибок и т.д.
А там не всегда в старших битах значение "0".
Кстати, насчет линии SCK - может от того, что я линию CS в неактивное состояние не перевожу, а сразу прямо выключаю SPI?

Я бы предположил еще что nCS успевает вернуться в неактивное состояние. Лучше бы SPI_WriteBuffer или не пользоваться либами, а написать самому.

Нет. В настройках SPI я определил, что линия CS не будет устанавливаться в высокий логический уровень при передаче.
Я когда передачу и окончательный прием заканчиваю, выключаю SPI - при этом аппаратно линия CS устанавливается в лог. "1".


Сообщение отредактировал Arlleex - Nov 14 2011, 19:44

[aaarrr]

Для ответов на команды - это хороший отличительный знак, что старшие биты всегда имеют значение "0".
Но есть и ответы на данные, маркеры ошибок и т.д.
А там не всегда в старших битах значение "0".

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

Кстати, насчет линии SCK - может от того, что я линию CS в неактивное состояние не перевожу, а сразу прямо выключаю SPI?

Очень даже может.

[Arlleex]

Хорошо, попробую не выключать SPI после последней передачи.
Тогда, если обобщенно сделать вывод о протоколе SPI-SD: никто толком интерфейс не разбирал (в смысле разработчики SD), и ожидать от карты можно чего угодно?

[aaarrr]

Тогда, если обобщенно сделать вывод о протоколе SPI-SD: никто толком интерфейс не разбирал (в смысле разработчики SD), и ожидать от карты можно чего угодно?

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

Все карты, которые мне до сих пор встречались, работали строго в соответствии со спецификацией. Все они без исключения отлично работают в SPI-режиме.

[Arlleex]

Посмотрел осциллограмму сигнала на линии SPCK во время передачи команды CMD0 и затем CMD8.
Последовательность такая у меня:
1) 80 синхроимпульсов при CS="1";
2) CMD0 [0x40 00 00 00 00 95];
3) CMD8 [0x48 00 00 01 AA 87];
Заканчиваю опрос линии MISO, когда в регистре данных прием SPI содержится значение, отличающееся от 0xFF.
На осциллограмме картина такая:
все передается четко по 8 бит, сначала 80 импульсов, затем 8 пачек по 8 импульсов (6 байт команда - и 2 раза опрос линии MISO до получения ответа R1 [0x01]), затем небольшая задержка, в течение которой выключается SPI и еще раз включается для передачи команды CMD8.
Далее - снова 8 пачек по 8 импульсов (опять же 6 байт команда и 2 байта опрос линии MISO до получения ответа R7 (значения, отличного от 0xFF)).
Соответственно, что получается:
первая пачка импульсов команды CMD8 - отправили 0x48;
вторая пачка импульсов команды CMD8 - отправили 0x00;
третья пачка импульсов команды CMD8 - отправили 0x00;
четвертая пачка импульсов команды CMD8 - отправили 0x01;
пятая пачка импульсов команды CMD8 - отправили 0xAA;
шестая пачка импульсов команды CMD8 - отправили 0x87;
седьмая пачка импульсов команды CMD8 - отправляем 0xFF для ожидания ответа, отличающегося от 0xFF (при этом проверяем ответ, сейчас он равен 0xFF);
восьмая пачка импульсов команды CMD8 - отправляем 0xFF и в этот раз получаем ответ 0xC1.

Далее проверять биты ответа R7 нет смысла, поскольку первый байт его мы уже приняли, но, как я и говорил, не в том виде, в котором хотелось бы получить: 0x05 [illegal command].

Сообщение отредактировал Arlleex - Nov 14 2011, 23:40

[aaarrr]

Далее проверять биты ответа R7 нет смысла, поскольку первый байт его мы уже приняли, но, как я и говорил, не в том виде, в котором хотелось бы получить: 0x05 [illegal command].

Ну, если на SCK ничего лишнего нет, то остается заключить, что карта все-таки не поддерживает CMD8. Как я уже писал, реакция в этом случае бывает разной - некоторые отвечают illegal command, другие молчат. Вполне можно допустить, что наблюдаемая картина является вариантом нормы (ведь фактически это молчание), а 0xC17F - не более чем совпадение. Недаром процедура проверки включает в себя сравнение отправленного и принятого аргумента - разработчики стандарта, по всей видимости, хотели застраховаться от возможных случайностей.

Возьмите для теста карту, которая точно должна ответить на CMD8 (любая HC). Вообще, лучше всегда иметь не менее полудюжины разных карт для экспериментов.

[Arlleex]

Ну, если на SCK ничего лишнего нет, то остается заключить, что карта все-таки не поддерживает CMD8. Как я уже писал, реакция в этом случае бывает разной - некоторые отвечают illegal command, другие молчат. Вполне можно допустить, что наблюдаемая картина является вариантом нормы (ведь фактически это молчание), а 0xC17F - не более чем совпадение. Недаром процедура проверки включает в себя сравнение отправленного и принятого аргумента - разработчики стандарта, по всей видимости, хотели застраховаться от возможных случайностей.

Возьмите для теста карту, которая точно должна ответить на CMD8 (любая HC). Вообще, лучше всегда иметь не менее полудюжины разных карт для экспериментов.

Совпадение с чем?
Спасибо, попробую другую карту (еще найти бы)
Кстати, нашел тут такую же проблему у наших зарубежных камрадов:
K <<< 4GB Sandisk SDHC

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
40 00 00 00 00 95 FF 01
48 00 00 01 AA 87 FF C1 7F FF FF FF <<< also 0xC1 ???
Источник:
http://embdev.net/topic/214834

Сообщение отредактировал Arlleex - Nov 15 2011, 08:01

[aaarrr]

Спасибо, попробую другую карту (еще найти бы)

А если на той же карте попробовать, скажем, CMD58?

Совпадение с чем?
...
Кстати, нашел тут такую же проблему у наших зарубежных камрадов:

Совпадение с ожидаемым ответом. У зарубежных камрадов карта точно не должна была отвечать illegal command, раз она HC.

Но выглядит странно, да. NRC не забыто случайно?

[Arlleex]

...NRC не забыто случайно?

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

Насчет команды CMD58 скажу чуть позже, для нее CRC не важно вроде как?

[aaarrr]

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

Я имел в виду именно NRC, а не NCR. После получения ответа от карты нужно выдать один пустой байт при нулевом CS перед следующей командой.

Насчет команды CMD58 скажу чуть позже, для нее CRC не важно вроде как?

В SPI не важно, пока не включите вручную.

[Arlleex]

Я имел в виду именно NRC, а не NCR. После получения ответа от карты нужно выдать один пустой байт при нулевом CS перед следующей командой.

Пустой - значит 0x00 или 0xFF?
Нет, такой задержки не выдерживал, да и не было указано в спецификации на SD (по крайней мере в моей), так же как и не было указано выдерживать 80 импульсов перед подачей команды CMD0.
Можете ли вы скинуть ссылку или прикрепить сюда файл вашей спецификации, поскольку, чувствую, что что-то не то у меня.
(У меня спецификация версии 2.00 физический уровень, и почему-то с сокращениями, не указано нигде никаких временных диаграмм, и т.д.).
// Передача команды CMD0
SPI_Enable(AT91C_BASE_SPI0); // Включение SPI0
SPI_Write(AT91C_BASE_SPI0, 1, 0x40); // Запись первого байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0x00); // Запись второго байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0x00); // Запись третьего байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0x00); // Запись четвертого байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0x00); // Запись пятого байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0x95); // Запись шестого(последнего) байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
while(response==0xFF)
{
SPI_Write(AT91C_BASE_SPI0, 1, 0xFF); // Сдвиг "1" на линию данных
response=SPI_Read(AT91C_BASE_SPI0); // Чтение данных
}
SPI_Write(AT91C_BASE_SPI0, 1, 0x00); // Запись шестого(последнего) байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Disable(AT91C_BASE_SPI0); // Отключение SPI0
//********************************************************************************
**********************
// Передача команды CMD8
SPI_Enable(AT91C_BASE_SPI0); // Включение SPI0
SPI_Write(AT91C_BASE_SPI0, 1, 0x7A); // Запись первого байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0x00); // Запись второго байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0x00); // Запись третьего байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0x00); // Запись четвертого байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0x00); // Запись пятого байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
SPI_Write(AT91C_BASE_SPI0, 1, 0xFD); // Запись шестого(последнего) байта команды CMD0
response=SPI_Read(AT91C_BASE_SPI0); // В ответе 0xFF
while(response==0xFF)
{
SPI_Write(AT91C_BASE_SPI0, 1, 0xFF); // Сдвиг "1" на линию данных
response=SPI_Read(AT91C_BASE_SPI0); // Чтение данных
}
USART_Write(AT91C_BASE_US0, response, 0);
SPI_Disable(AT91C_BASE_SPI0); // Отключение SPI
while(1);
}

В USART после передачи команды CMD58 приходит тот же ответ, первый байт 0xC1, и, допустим, даже если сдвинуть на несколько битов влево, получим нелегальную команду, а это означает (по блок-схеме из спецификации), что данная карта памяти не является SD.

Сообщение отредактировал Arlleex - Nov 15 2011, 11:48

[aaarrr]

Пустой - значит 0x00 или 0xFF?

0xFF. Удобно отправлять его после получения ответа перед снятием CS.

Можете ли вы скинуть ссылку или прикрепить сюда файл вашей спецификации, поскольку, чувствую, что что-то не то у меня.
(У меня спецификация версии 2.00 физический уровень, и почему-то с сокращениями, не указано нигде никаких временных диаграмм, и т.д.).

 Part1.pdf ( 649.69 килобайт ) Кол-во скачиваний: 842

Для работы достаточно этого и имеющейся у вас упрощенной 2.0

[Arlleex]

Вот видимо из за этого времени NRC и были проблемы.
Сейчас, после получения ответа на CMD0, отправил 0xFF и затем отправил команду CMD8 после чего принял ответ R7 с содержанием старшего байта (R1), равным 0x01, что соответствует спецификации 2.0 или позднее.
Верно?
Кстати, как скачать ваш документ, отсюда не получается.

[aaarrr]

Верно?

Похоже на то.

Кстати, как скачать ваш документ, отсюда не получается.

Странно, счетчик идет.

[Arlleex]

Все, нашел.
Ну что же, большое человеческое спасибо Вам, aaarrr.
Надеюсь, если снова возникнут проблемы, Вы снова откликнитесь

[aaarrr]

Надеюсь, если снова возникнут проблемы, Вы снова откликнитесь

Да без проблем

[Arlleex]

Добрался до команды CMD58.
Что собственно она у меня представляет:
[0x7A 00 00 00 00 FD]
Проверяю ответ, 10 раз команду повторяю, и он один и тот же:
R3=0x01 00 FF 80 00
Хотя бит Card power up status bit уже наверняка должен быть установлен, поскольку этот бит устанавливается, когда происходит стабилизация питающего напряжения.

[aaarrr]

Хотя бит Card power up status bit уже наверняка должен быть установлен, поскольку этот бит устанавливается, когда происходит стабилизация питающего напряжения.

Он должен не установиться, а, наоборот, сброситься.

[Arlleex]

Он должен не установиться, а, наоборот, сброситься.

Bit 31 - Card power up status bit, this status bit is set if the card power up procedure has been finished.
...
The Card Capacity Status bit is valid after the card power up procedure is completed and the
card power up status bit is set to 1.

[aaarrr]

Пардон, мимо смотрел.

А ACMD41 отправили? Без нее, насколько я помню, он не взводится.

[Arlleex]

По блок-схеме из спецификации сначала передается команда CMD58, а затем только ACMD41, предварительно необходимо выдать команду CMD55, чтобы указать, что следующая команда будет спецификационная (AXXXx).

[aaarrr]

Первый раз CMD58 подавать не обязательно - это нужно только чтобы выяснить диапазон питания, поддерживаемый картой. Бит готовности в этом случае не взводится.
То есть последовательность такая: CMD0->CMD8->[CMD58]->ACMD41->CMD58. Последнюю повторяем до появления бита готовности или тайм-аута в 1 секунду.

[Arlleex]

Ясно.
Насчет команды ACMD41 и остальных ACMDx: перед ними нужно передать команду CMD55?
А далее как быть? Все последующие команды будут восприниматься как команды ACMD или CMD55 указывает только на следующую команду? А дальше - команды будут восприниматься как обычные CMD?
Например:
CMD0;
CMD8;
CMD55 (указывает контроллеру SD карты памяти, что следующая команда будет из разряда ACMD);
ACMD41;
CMD58 (а эта команда будет уже относиться к обычным CMD, поскольку не была передана непосредственно после команды CMD55).
Верно?
И зачем сделали разделение на CMD и ACMD?
Неужели только из-за того, что не хватило разрядности указателя индекса команды 6 бит?

Сообщение отредактировал Arlleex - Nov 15 2011, 19:43

[aaarrr]

Насчет команды ACMD41 и остальных ACMDx: перед ними нужно передать команду CMD55?
А далее как быть? Все последующие команды будут восприниматься как команды ACMD или CMD55 указывает только на следующую команду? А дальше - команды будут восприниматься как обычные CMD?
Например:
CMD0;
CMD8;
CMD55 (указывает контроллеру SD карты памяти, что следующая команда будет из разряда ACMD);
ACMD41;
CMD58 (а эта команда будет уже относиться к обычным CMD, поскольку не была передана непосредственно после команды CMD55).
Верно?

Верно, CMD55 действует только на следующую команду.

И зачем сделали разделение на CMD и ACMD?
Неужели только из-за того, что не хватило разрядности указателя индекса команды 6 бит?

Еще хотели SD и MMC частично подружить, а частично растащить. В общем, как я понимаю, тут больше политические причины повлияли, нежели технические.

[Arlleex]

А какую файловую систему используют SD карты?

[aaarrr]

Стандарт подразумевает использование FAT16 и FAT32. Но на деле можно использовать любую по большому счету.

[Arlleex]

Еще раз доброго времени суток.
Перед тем, как использовать передачи данных, необходимо указать размер блока данных, которые будут передаваться (поскольку это SDSC).
Итак, передаем команду CMD16, с аргументом 512 (длина блока данных 512 байт).
Это как раз равно физическому сектору.
Но, если я использую длину блока данных, например, 1 байт, можно ли мне адресовать их побайтно, например - 0x00 - первый байт, 0x1FF - конец адресного пространства первого физического сектора.
А если, например, установили длину блока данных 16 байт, то указываем начало первого блока данных:
0x00 - и с него читаем, при этом конец первого блока будет 0x1F, а начало второго блока данных в этом же секторе 0x20.
Нельзя будет обратиться по адресу одного элемента, например 0x01, поскольку мы должны считать сразу 16 элементов, а потом уже из этого массива 16ти чисел выбирать нужный элемент, а адрес можно задавать любой, он определяет начальную ячейку, с которой будет начата передача данных.
НО!
В спецификации на SD карту памяти указано, что нельзя при передачах данных нарушать границы одного сектора. Верно ли я понимаю, что, к примеру, нельзя при длине блока данных 16 байт указать адрес передачи данных 0x1FE, поскольку произойдет нарушение границ чтения одного сектора, ведь останется 2 байта в секторе №1, и 14 байтов в следующем секторе, а карта памяти непосредственно выдаст ошибку?

Пожалуйста, проверьте все до слова, что я тут написал, поскольку сейчас это для меня важный шаг понимания структуры организации ячеек памяти SD карты.

[aaarrr]

Верно ли я понимаю, что, к примеру, нельзя при длине блока данных 16 байт указать адрес передачи данных 0x1FE, поскольку произойдет нарушение границ чтения одного сектора, ведь останется 2 байта в секторе №1, и 14 байтов в следующем секторе, а карта памяти непосредственно выдаст ошибку?

Совершенно верно.

В стандарте есть один очень важный момент: все без исключения карты обязаны работать с блоками по 512 байт. Остальное на усмотрение производителя. Поэтому единственный универсальный подход - оперировать тоже исключительно 512-байтными блоками и никак иначе.

[Arlleex]

7.3.3.2 Start Block Tokens and Stop Tran Token
Read and write commands have data transfers associated with them. Data is being transmitted or
received via data tokens. All data bytes are transmitted MSB first.
Data tokens are 4 to 515 bytes long and have the following format:
For Single Block Read, Single Block Write and Multiple Block Read:
...

Как верно переводится данная строка из спецификации? И что она означает?

[aaarrr]

В этой строке представляется не совсем корректным употребление термина "token" для описания всего блока данных, включающего в себя стартовый байт (который, собственно, и является token'ом) + 1..512 байт данных + 2 байта CRC.

[Arlleex]

Ясно, т.е. они имели ввиду длину всего передаваемого блока данных.
А что насчет содержимого памяти SD карты? Если я ни разу не форматировал SD карту памяти на компьютере, да и нигде вообще, а только инициализировал и прочитал блок данных, содержимое всех байтов в секторе обязательно должно быть равно значению "0"? У меня большинство байтов равны "0", но встречаются и такие, где байты отличны от значения "0". Это нормально? Ведь с завода они идут уже форматированными вроде бы?

[aaarrr]

Это нормально? Ведь с завода они идут уже форматированными вроде бы?

Это нормально. С завода идут уже отформатированными. В тех областях, которые не содержат структур файловой системы, может быть все что угодно.

[Arlleex]

Доброго времени суток.
При передаче данных на SD карту памяти (при записи одного сектора) необходимо указать верный CRC. Но мне не нужно подсчитывать каждый раз CRC, необходимо отключить проверку CRC. Это можно сделать командой CMD59, как я понял. Но почему же предыдущие команды не принимали во внимание поле CRC в ее передаваемом слове?

[aaarrr]

В режиме SPI CRC по умолчанию отключен.