Здравствуйте,
Появилась проблема с отказом SD card. Устройство включено 24ч.
Процессор работает с контролером карты выполненный в FPGA. Контролер проектировал самостоятельно.
По определенным событиям контролер обращается к карте за массивами данных, т.е. используется только режим чтения с карты.
После некоторого промежутка времени (около двух месяцев) в секторах начинают пропадать данные . При том более современные карты эту проблему повторяют в меньший промежуток времени.
Определил что сектора портятся там где больше доступа было к сектору.
Работа контролера: инициализация, после CMD3 переключение Fclk, переход в трансфер CMD7, переключение шины ACMD6
Находясь в режиме трансфера формирую по запросу команды чтения CMD17 и пакетного чтения CMD18.
Оставаясь в режиме трансфера ожидаю следующий запрос на чтение и т.д.
Закрылись предположения что причиной может быть нахождение в трансфер режиме. Решил из трансфера перейти в standby и по запросу чтения переключаться в трансфер.
Появилась проблема, Находясь в трасфер режиме формирую команду чтения и желаю после чтения выйти в stndby. CMD17 получаю ответ R1-> затем CMD13 дожидаюсь режима трансфер и подаю CMD7 - и здесь ТУПИК!
- ожидаю r1 - без ответа
- пробую опрашивать cmd13 -> r1 без ответа
- пробовал cmd7 и RCA и с 0 передавать, без ответа.
на CMD0 реагирует. но думаю не корректно подымать весь цикл инициализации.
PDF не помогает(((, ПРОШУ ПОМОЩИ

Что вы понимаете под "пропадают данные"?
Иногда карта может задумываться надолго, но рано или поздно ответит.
Если ответ не нужен, то посылайте CMD12 - это прервет операцию чтения.
Переходить из "tran" в "stby" и обратно я бы не советовал.
У меня карточки годами находятся в "tran" и ничего. Чтение, правда, эпизодическое; записи вовсе нет.
Заметил, что со временем карты могут начинать "задумываться" даже при эксплуатации только в режиме чтения.
Задержки могут быть и по 600мс.

Все правильно: после перехода в stby карта ответить ничего не может. Ответ R1b можно получить только при переходе из stby в tran, но не наоборот.



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

"пропадание данных" - при верификации с исходным массивом в необходимом секторе читаю 0xFF. Это единичные сектора но они по факту испорчены.
Цикл ожидания ответа стоит достаточно большой.
карты до 2ГБ (SD) - годами стояли и работали, карта всегда была в трансфер режиме.
а вот с новыми SDH - реально стали чудеса происходить. Первые 4Гб class4 работали по 6-12 месяцев. 8Гб - до 6 уже не дотягивали. А вот не давно купил Silicon Power 16Гб 10class long life - посыпались через три дня
Поэтому пытаюсь его вернуть в stby , для опыта




Я в ходе чтения pdf и опыта понял, что переход в stby происходит без ответа. Вопрос , как его вернуть назад в Trans. я подавал CMD7 с последним RCA и не получал ответа.
Возможно я не до конца понял ответ R1b , в моем случае после команды CMD7 перехожу в ожидание r1 .

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

На счет старения нанда, то 99% контроллеров внутри сд карты переводят ее в режим ридонли, и нигде уже эту карту не заставить снова работать на запись, так что ТСу легко проверить, если его "дохлые" карты нигде не форматируются, то значит было место интенсивной записи, а если отформатируются и будут работать на компе - пусть ищет ошибки у себя.

ЗЫ. Сегодняшние карты большого объема использут TLC NAND, ресурс которого очень мал, если писать большие объемы, то выравнивание износа толком не сработает, а значит ресурс такой карты очень мал..

Не перегибаю. Есть такой эффект при интенсивном чтении, погуглите "nand read disturb".


RCA точно совпадал? Уж простите мою "подозрительность", просто это очень частая причина.

Небольшая преамбула,
На устройстве нет винды, Контролер самописный на ПЛИС. Работает устройство в серии больше 10 лет.
Первые карты которые устанавливались на устройстве были 64МБ, потом был апгреид с приходм SDHC .
Команда CMD24 - заись сектора, у меня вообще закомментирована.
А сектора "киснут". И это стало реальной проблемой.



Сегодня еще раз код пересмотрю и сделаю несколько тестов с переходами trans<->stby

Насколько интенсивно производится чтение?

Вы точно уверены что это данные из сектора? Пробоволи считать их повторно или на ПК?
После команды чтения следует ответ на команду, а затем нужно ждать признака данных (очень долго).
После признака данных идут данные и CRC. Ни разу, ни при каких обстоятельствах не видел,
чтобы изначально рабочая карта начала выдавать 0xFF вместо данных.
Я много лет собираю таких "уродцев" в свою коллекцию, но ничего подобного не встречал.
Есть две "левые" карточки, купленные в отделе носовых платков, дык, одна вообще не читается,
а на второй работают только первые 128МБ из 2ГБ, но такие карты не для серьезного рассмотрения.

Мне кажется я уже тут выкладывал результаты исследований карт при чтении потока в реальном времени, но не могу найти где именно.
Чтение велось блоками по 256Б и по 8КБ (по 10 000 блоков в каждом эксперименте).
Все данные считываются верно, но с различной задержкой.
Иногда задержка настолько велика, что поток реального времени невозможен (в звуке появляются щелчки).
Такие события имеют желтый фон.

Спасибо за настойчивое указание проверить RCA, действительно была зависимость по которой содержимое сбивалось.
Результат, нормальное поведение перехода между состояниями.
Как только соберу статистику по состоянию карт, обязательно опубликую здесь
Контролеров порядка 5тыщ в работе с разными типами карт и производителей. Есть где разгуляться)

Грабли - вещь универсальная


Любопытно будет посмотреть. А все же, насколько интенсивно идет чтение?

Чтение вызывается несколько раз за суткм. но в этот час чтение идет очень интенсивное