Приветствую.
Настраиваю MMC/SD Controller, пишу-читаю данные, вроде бы всё работает. Но возникла проблема, при постоянной записи данных контроллер периодически начинает тупить.
Последовательность записи данных следующая:
1) Отправляю команду SET_BLOCKLEN
2) Настраиваю фифо на передачу
3) Заполняю фифо до упора
4) Отправляю команду WRITE_BLOCK
5) При наличии в фифо свободного места записываю все остальные данные
6) Жду установки DATDNE в MMCST0

Тупит в месте проверки DATDNE, иногда почему-то DATDNE долго не устанавливается. С чем это может быть связано?

идёт скидывание внутреннего кэша в физическую память. там вроде как тайминг до 200 ms может быть
(если я по памяти назвал вам верные цифры, но порядок такой). Лучше загляните на uSD карточки доки, там вроде как пробегало.

Если можно по-подробнее.
Данные в фифо mmcsd-контроллера записываю при условии, что фифо не полон циклом. После записи последних 4-х байт жду DATDNE. И вот тут в большинстве случаев DATDNE устанавливается через ~1,2 мс, но иногда более чем через 400 мс.
Как понимаю, тупит mmcsd-контроллер.

Это когда ему внутри что-то стереть надо, то идет такая пауза. Это для всех карточек так. Для каких-то больше, для каких-то меньше. Бороться частично можно предварительным стиранием карты и записью больших блоков (128-256КБ).

Но DATDNE - флаг MMCSD-контроллера процессора, т.е. если пакет данных в фифо запихнули и они ушли на память, то он и должен установиться. Связи со стиранием-записью самой карты не вижу, может что-то не понимаю, поправте.

Перечитал всё что писали, потыкал осцилом на плату (жёлтый - ожидание DATDNE, зелёный - линия DATA0), нашёл в даташите, что низкий уровень на DATA0 - сигнал BUSY (т.е. контроллер памяти перекидывает данные в NAND-flash). Вопрос, почему в некоторых случаях этот BUSY длится почти 500 мс? Нормально ли это?
Данные пишу в цикле последовательно увеличивая адрес блоком в 512 байт.

В MMC/SDSC/SDHC встроенный контроллер занимается перемешиванием блоков с целью равномерного износа.
Также, пока возможно (есть запас) производится рамаппинг сбойных блоков.
Вот на построение таблицы переадресации и тратится время.
Поэтому в описании декларируются задержки до 700-800мс. К этому нужно быть готовым.
Даже если писать потоком, последовательные сектора, то 1-2 паузы в самом начале присутствуют.
Далее, вроде всё быстро.

Похоже, что-то неправильно делаю. Сравнил со старым проектом (там SDHC карта в режиме SPI), таких длительных пауз (ожидания пока BUSY) нет. Тут используется eMMC, но таких оличий ведь быть не должно.
Проблемка остаётся актуальной.

Переделал алгоритм записи:


Получаю, что иногда долго висит на 0 пункте, т.е. состояние у памяти Programming State (prg).
Вопрос - как это обойти? Что-то не совсем понимаю каким образом большой буфер спасёт ситуацию. Может есть ещё какой-то способ?

Хотел это попробовать, но при отправке команды CMD20 (WRITE_DAT_UNTIL_STOP) память вообще дохнет, не отвечает R1. Нашёл в доке, что команда должна работать только в режиме шины 1х, но и это не помогло.


Почему получаем разное время записи физической памяти? Один раз буфер 512 байт записывается во внутреннюю NAND за 1.5 мс, а иногда BUSY держится целых 500 мс?

Я, года 3 назад, проводил такой эксперимент.
1) SD/SDHC или MMC пишу по одному сектору последовательные адреса, 100 секторов
2) пишу по 1 сектору произвольные сектора по псевдослучайной таблице адресов,тоже 100 секторов
Так вот время записи отличается на порядки, не шучу. Точных значений не помню, но помню, что
неприятно удивило.
Потом в документации на SD прочитал, что нужно быть готовым к состоянию карты - занято - до ~700мс.
Причины я выше приводил.
Поэтому я всегда, где требовалась скорость, через SPI или SDIO писал строго последовательные адреса.
И то, при первой записи, почти всегда есть занятость 300-600мс. Наблюдал осциллографом.
Далее идет равномерно.
Кстати, есть современные карточки, в которых не предусматривается алгоритм перемешивания блоков и
горячей подстановки сбойных секторов. Их признак - они придназначены только для exFAT. В них не должно быть
таких пауз.

Что-то не могу понять: в CSD есть поля WRITE_BL_LEN и READ_BL_LEN, которые определяют размер блока при чтении и записи. Данные поля определены как READ ONLY, т.е. получается что они определяют максимальную длинну блока данных на чтение/запись и её значение я изменить не могу (у моего чипа они равны 9 -> максимальный размер блока 2^9=512 байт).
Что тогда делает команда SET_BLOCKLEN, если повлиять на размер блока я не могу?

может ключевое слово максимальный?
то есть меньше можно...

Есть ещё и READ_BL_PARTIAL (WRITE_BL_PARTIAL) также READ ONLY и равны нулю - говорит о том, что и меньше нельзя.
В чём тогда смысл SET_BLOCKLEN для данной памяти? Или здесь данную команду можно и не использовать, а размер блока данных у чипа всегда постоянен?

в этой нельзя, в какой то другой можно, это что повод не поддерживать команду?

http://we.easyelectronics.ru/AVR/mmcsd-i-a...a-s-kartoy.html

Команда CMD16 (SET_BLOCKLEN) в этом случае устанавливает размер блока для чтения. Если READ_BLK_MISALIGN установлен, можем читать как нам приспичит=) с нарушением границ блока. Стоит, однако, помнить, что только что сказанное не относится к картам SDHC, где размер блока чтения всегда равен 512.

Так и есть, для моего девайса эта команда вообще не может ничего менять (как-то так), при попытке увеличить размер блока данных выдавало ошибку BLOCK_LEN_ERROR, сразу не обратил внимания и не мог понять почему дохнет при попытке записи 1024 байт.

Вышеописанная проблема решилась использованием WRITE_MULTIPLE_BLOCK (пишу сразу 2 сектора по 512 байт) вместо WRITE_BLOCK, стало шустрее работать (при постоянной записи последовательных адресов максимальная длительность BUSY получилась где-то 10 мс). Не знаю пока с чем это связано, может с тем, что минимальный размер стираемого сектора 1024 байта.

друзья помогите
на процессоре AM1808 нужно завести SD/MMC
плата am8118
скачал AM1808_StarterWare_1_00_03_03 там не оказалось
примера работы с SD
подскажите где найти рабочий пример