SD-card: выход из строя, не определяется компьютером, Выработан ресурс? как проверить? Опции

[Ruslan1]

Здравствуйте!

В одном из устройств произошел массовый выход из строя SD-карточек (8 из 10 тестируемых), причем странно себя ведут:
в устройстве (интерфейс SDIO, софт на базе FatFs)- карточка детектируется, файлы с них считываются корректно, но при попытке записи выдает ошибку.
В компьютере- карточка вообще не детектируется. (проверено на разных компьютерах с разными ридерами).

Проблема точно не в железе устройства- это же железо с другим софтом используется долгое время, проблем нет. То есть проблема в моем новом софте.
Есть поток данных, записываемых на карточку, примерно 25 килобайт в секунду. Данные пишутся в 15-минутные файлы, файлы старее пары суток удаляются. То есть получается кольцевой буфер данных.

Главный вопрос: как можно загнать карточку в такое "окирпичивание?"

Похоже на выработку ресурса: проблемы на всех карточках начались практически одновременно с разницей в 1-2 дня, после примерно 2 месяцев работы.
Как проверить эту версию? Есть ли какие-то средства чтобы проверить внутреннее здоровье SD-карточки, вроде того как это на SSD делается?

Ну и еще вопрос: Почему в устройстве эти SD карточки читаются (но не пишуться), а в компьютере даже не детектируется?

Каким софтом их поковырять? я кроме WinHex и не помню ничего приличного для внутреннего ковыряния дисков.

[k155la3]

Маловероятно, конечно, но.
- Нет ли "просадки" питания на карту в момент записи и не находится ли оно на пороге работоспособности по напряжению.
- Соблюдаются ли временные диаграммы (если таковые имеются) при записи.

[Ruslan1]

Я понимаю, что внутренние используемые механизмы в карточке могут значительно увеличить время жизни карточки. Но мне нужно понять на что минимально рассчитывать, как это оценить.


Вопрос №1
как можно посчитать степень износа, если предположить что :
размер стираемого блока-128К
размер используемого диска- 16GB, то есть 125К блоков
время жизни блока - 1000 стираний

Тогда в худшем случае (на каждое обновление переносится целый блок):
количество обновлений = 125К блоков * 1000 стираний = 125M = 125e6

при количестве обновлений 1 в секунду: получаем время жизни карточки 125e6 секунд, это 1446 дней.

Это правильная оценка?
-------------------------------------------

Вопрос: №2
Что именно я должен считать обновлением, чтобы определить насколько сильно я изнашиваю эту карту?

Ведь нельзя считать таким обновлением просто добавление информации на то место сектора/страницы/блока, которое до этого было 0xFF ?

Я считаю, что обновление- это изменение, которое требует стирания блока. Я прав?
(Хороший пример такого обновления- это запись в FAT при изменении файла)
-------------------------------------------

Вопрос №3:
А как контроллер Флеш поймет, что данные в хвосте блока это мусор, а не данные, которые нужно переносить? Видимо, никак. И тогда получается, что на каждую запись сектора карточка будет тащить целый новый блок?
Как этого можно избежать? Почистить неиспользуемые сектора в FF? Дать команду стирания чего-нибудь там?
Есть какой-то способ помочь карточке, иначе ведь совсем катастрофа с ресурсом?

У меня, кстати, получается именно эта проблема: я писал по 40 секторов в секунду. Если предположить что контроллер карточки каждый раз занимался переносом блоков, то получаю ресурс 36 дней, что очень похоже на мой случай (у меня вышло немного больше, но может и ресурс блока немного больше чем 1К стираний).
-------------------------------------------

Вопрос №4:
Кэширование и запись на карточку большими кусками, скажем, 128К, поможет?
Upd: поиск помог найти вот это, буду копать туда:

Alex11, Jul 14 2014, 22:27
Мы довольно много экспериментировали с SD в разных режимах. Во-первых, там есть команда мультисекторной записи. При этом небольшая пауза возникает только после записи многих секторов (но не факт, что после всех, запрошенных в команде). Кроме того, особенно при работе с не свежеформатированной карточкой, у нее возникают паузы до 0.5 сек на внутренние нужды - стирание блоков и переписывание частично заполненных. Реально помогает только запись блоками по 64 - 128 кБ в зависимости от карты.

[controller_m30]

Вопрос №1
как можно посчитать степень износа, если предположить что :
размер стираемого блока-128К
размер используемого диска- 16GB, то есть 125К блоков
время жизни блока - 1000 стираний

Тогда в худшем случае (на каждое обновление переносится целый блок):
количество обновлений = 125К блоков * 1000 стираний = 125M = 125e6

при количестве обновлений 1 в секунду: получаем время жизни карточки 125e6 секунд, это 1446 дней.

Полностью проверить это допущение займёт всё те же 1446 дней - а это долго.

Можно сделать тест на износ только одного блока 128К, но при разных условиях. Понадобится две карты.
Тест 1.
Однократно заполнить все сектора карты данными, чтобы отнять у встроенного контроллера ресурс для перестановки блоков. И "протереть дырку" в каком-либо блоке 128К. Подсчитать количество перезаписей до отказа карты.
Тест по идее получится коротким - около 1000 перезаписей.

Тест 2.
Сделать то же самое, но с новой, неформатированной картой, где у контроллера имеется огромный ресурс для перестановок. И попробовать "протереть дырку" теперь.
Предположительно, "дырка протрётся" либо после 125К перезаписей, либо после 125К х 1000. Это будет зависеть от "понимания" контроллером карты что такое резервный блок: тот который просто не писался ни разу (тогда ресурс 125К), или тот который не писался ни разу пользователем (тогда ресурс 125К х 1000).
Возможен ещё вариант - просто 1000 записей. Будет означать, что контроллер не умеет переставлять блоки.

В зависимости от результатов можно будет предложить разные варианты использования карты. Например, если будет результат 125Кх1000, то достаточно будет отформатировать карту 16Гб, как будто она 8Гб, а оставшиеся нетронутыми блоки отдать контроллеру для перестановок. В этом случае не придётся вообще ничего менять в ПО.

[aaarrr]

Однократно заполнить все сектора карты данными, чтобы отнять у встроенного контроллера ресурс для перестановки блоков.

Думаете, можно отнять? Сложно предположить, что такая ситуация не предусмотрена логикой работы
контроллера. Полный физический объем носителя пользователю недоступен.

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

[jcxz]

но логичнее потратить это время на оптимизацию работы собственного ПО для снижения нагрузки.

Вот именно!
А может у ТС какой-то косяк в алгоритме записи? О котором он не подозревает.
Например: в процессе записи 15-минутного файла многократно открывается/закрывается файл? Или ещё как-то делается обновление записи директории о файле? И вместо одной модификации FAT получается много. Или файл пишется порциями, некратными размеру кластера, со сбросом буферов на диск между порциями?

[Ruslan1]

А может у ТС какой-то косяк в алгоритме записи? О котором он не подозревает.
Например: в процессе записи 15-минутного файла многократно открывается/закрывается файл? Или ещё как-то делается обновление записи директории о файле? И вместо одной модификации FAT получается много. Или файл пишется порциями, некратными размеру кластера, со сбросом буферов на диск между порциями?

Я говорил про 40 записей в секунду- это я завел счетчик записанного функцией disk_write(), так что я точно уверен что в DMA попадает очередь именно на это количество секторов.

Про то что мой косяк- только на это и надежда, свои косяки можно исправить
Действительно косяки конечно есть, например самый грубый: практически всегда в SD-карточку из моего кода идет команда записать данные только длиной в один сектор. Хотя внутри все сделано универсально, с использованием CMD25.

В-общем, на выходные попробую подготовить несколько тестов в параллель на нескольких приборах, посмотрю кто дырку протрет быстрее.

Кстати, первым делом стоит сократить число копий FAT до одной, если их по старинке две.

Да, спасибо за напоминание, у меня их две, по дефолту. Не спасало, млин, ни разу
Это хороший и простой метод уменьшить число записей, да и ускорение неплохое.

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

Я только попробую потестировать насколько быстро убьется карточка если я буду на нее писать:
1) короткими блоками, по 1 сектору (близко к тому что сейчас имею)
2) блоками по 16 килобайт (удобный для меня вариант)
3) блоками по 128 килобайт (максимально возможный, еще приемлемый вариант)

Буду писать как можно быстрее. Если увижу разницу между результатами- это значит есть за что бороться.

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

А "оптимизация работы собственного ПО для снижения нагрузки" уже идет. Хвала Святому Гиту, несколько бранчей позволяют обойтись без каши в коде

[jcxz]

Действительно косяки конечно есть, например самый грубый: практически всегда в SD-карточку из моего кода идет команда записать данные только длиной в один сектор. Хотя внутри все сделано универсально, с использованием CMD25.

У меня ещё вот какая версия возникла:
Вот мы говорим, что карта имеет wear leveling. Ok - имеет. А как он реализован? Очевидно, что должна быть некая таблица переназначения логических секторов на физические. Когда карта работает (питание подано) эта таблица может находиться (и модифицироваться) в ОЗУ. Но она также должна сохраняться/восстанавливаться при выкл/вкл питания. А в какой памяти её хранить тогда? По размеру она небольшая (таблица), можно в карту включить что-то типа FRAM.
А если она внутри пишется не во FRAM, а во флешь (для экономии)? Тогда можно наверное зарезервировать под это дело много секторов обычной флешь (кольцевой буфер секторов) и, при переназначении очередного сектора, дописывать некую запись. А при восстановлении питания, строить таблицу в ОЗУ на основании этих записей о модификации.
А может быть вся таблица по сигналу "сбой питания" быстро скидывается в какой-то один блок флешь. Но тогда если например карта будет работать так: записали 1 сектор, включили/выключили питание, записали следующий сектор, опять включили/выключили питание, и т.д. И так этот блок флешь быстро протрётся.
Я думаю, что у разных производителей карт, алгоритм работы системы wear leveling может быть построен по-разному и иметь разные преимущества и недостатки для разных режимов работы.
И тогда на одной карте такой режим: запись сектора и вкл./выкл. питания - получится ресурс карты такой же как и без выключений питания, а на другой - ресурс будет значительно меньше.
Поэтому и есть отличия, что дохнут только определённые карты.