SDcard проблема с CDMD7, правильный select/deselect карты Опции

[hardgame]

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

Сообщение отредактировал hardgame - Feb 22 2018, 17:07

[adnega]

После некоторого промежутка времени (около двух месяцев) в секторах начинают пропадать данные

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

[aaarrr]

Появилась проблема, Находясь в трасфер режиме формирую команду чтения и желаю после чтения выйти в stndby. CMD17 получаю ответ R1-> затем CMD13 дожидаюсь режима трансфер и подаю CMD7 - и здесь ТУПИК!
- ожидаю r1 - без ответа

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

После некоторого промежутка времени (около двух месяцев) в секторах начинают пропадать данные . При том более современные карты эту проблему повторяют в меньший промежуток времени.

Заметил, что со временем карты могут начинать "задумываться" даже при эксплуатации только в режиме чтения.
Задержки могут быть и по 600мс.

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

[hardgame]

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

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

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

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


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

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

[mantech]

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

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

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

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

[aaarrr]

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

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

Вопрос , как его вернуть назад в Trans. я подавал CMD7 с последним RCA и не получал ответа.

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

[hardgame]

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

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

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

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

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


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

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

[aaarrr]

А сектора "киснут". И это стало реальной проблемой.

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

[adnega]

"пропадание данных" - при верификации с исходным массивом в необходимом секторе читаю 0xFF. Это единичные сектора но они по факту испорчены.

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

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

Прикрепленные файлы

 SDIO_stat_2.pdf ( 56 килобайт ) Кол-во скачиваний: 13

 

[hardgame]

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

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

[aaarrr]

Спасибо за настойчивое указание проверить RCA, действительно была зависимость по которой содержимое сбивалось.

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

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

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

[hardgame]

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


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

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