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

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

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

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

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

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

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

А в чём плюс такого кольцевого буфера?
В стандартном (без файлов, когда для кольца выделена цепочка последовательно-расположенных секторов) кольцевой буфер помогает распределить износ равномерно по всем секторам кольца.
А в вашем случае - какой смысл? При создании/удалении файлов очевидно, что каждый раз будет писаться одно и то же место в FAT и в записи директории. Эти места будут быстро изнашиваться.


Если карта поддерживает wear leveling, то даже в вашем алгоритме не должно быть неравномерного износа. Но если нет: на месте FAT и месте записи директории будет дырка.

Данная структура используется не для оптимизации флешки, а для удобства работы с данными.
Эти данные (15-минутный отрезок) могут быть запрошены по времени и доставлены. И автоматически удаляться после окончания времени жизни файла. Время жизни разное может быть, от часа до пары недель.

Ну, если SD вдруг не поддерживает внутри wear leveling то вообще все плохо с FAT. Но вот как узнать что и как оно там поддерживает? Карты Sandisk, вероятность того что не фейк очень большая (так как не я лично с территории завода-производителя вывозил, то 100% не могу дать, что не фейк, все возможно).

Нашел, кое-что, вот тут немного обсуждают про выравнивание, по аналогии можно попробовать найти материалы на современные карточки

Скажите пожалуйста, какие могут быть варианты для такого поведения:
- у меня в устройстве (использую SDIO) карточка читается нормально, но не может быть записана
- в компьютере карточка вообще не определяется и не детектируется. На андроиде(в телефоне)- тоже просто не видна, будто и не вставлена.

Если читать посекторно в моем устройстве- то все сектора на месте, не вижу разницы между "нормальной" и "мертвой" карточками.

читал регистры SD- карточки - тоже нет разницы между карточками.

Как такое может быть: оно есть и я могу доступиться до карточки (пусть и только по чтению), а операционки не могут даже ее наличие определить ???

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

А запись этих секторов работает? Частоту понизить? По SPI обратиться?

Вообще, переход в read-only указывает на повреждение внутренних структур данных - тех, что отвечают за трансляцию адресов, выравнивание износа и т.п.
Возможные причины:
- низкое качество самих карт
- проблемы с питанием
- очень высокий износ из-за ошибок в софте МК

Случаются и совсем чудеса: был у меня лет 10 назад замечательный китайский кард-ридер, после общения с которым карты
совершенно разных производителей начинали жутко тормозить при записи (скорость падала примерно до ~25КБайт/с). Причина
так и осталась загадкой.

Спасибо всем!
Уважаемый aaarrr собрал вместе то что озвучено в разных постах, именно из этого списка вероятностей я и исхожу.

Про низкое качество карточек- думаю стресс-тест провести (я их ем партиями по 100-200 штук, одну из партии всегда можно попробовать убить для тестов). Стресс-тест на запись прямо сейчас запущу, посмотрим сколько суток протянет (на писишке с USB3, чтоб побыстрее). (Upd: хороший тест еще поискать нужно, мда..)

Про питание- тоже возможно. Дело в том, что именно эти 10 приборов (из которых на многих SD карточка и "окирпичилась") питаются от одного общего внешнего блока питания (в других применениях устройства снабжены индивидуальными внешним БП). Через встроенный DCDC прибора в принципе много чего может пролезть короткого и злобного. Но опять же- это никак не сказалось на окружающей электронике на этой же плате, ни сбросов-зависаний процессора, ни каких-нибудь других проблем- только SD карточка.

Я сам склоняюсь к причине "очень высокий износ из-за ошибок в софте МК". Так как именно для этих 10 штук была разработана своя версия софта. Вроде бы не сильно отличается от стандартной применяемой в сотнях приборов, но все же.

Про "просто запланированный высокий износ":
Сделал счетчик записанных секторов- получилось что реально пишу около 41 сектора в секунду, это 3.5 миллиона секторов в сутки. Проверю точнее, но конкретно область FAT обновляю примерно раз в секунду.

Ну и риторический вопрос- имеет ли смысл следить, в какой сектор я пишу, или этот wear leveling все берет на себя?
Я так понимаю, при расчете нужно исходить от пустого пространства и ресурса на сектор?
У меня: примерно 10 гигабайт свободного пространства, и 2 гигабайта переписывается в сутки. Если выравнивание работает, то даже при ресурсе сектора "1 тысяча записей" должно продержаться 13 лет.

Конкретно у меня карточки микро-SD Сандиск 16G Ultra 10 класс (SDHC UHS-I)

У современных карточек снаружи не нужно следить за равномерностью износа, это все делается внутри. Запрет записи, как уже было сказано, включается при невозможности восстановить ошибочные данные в служебных областях карты, чтобы не потерять данные. Почему это произошло так рано - не знаю. Не может ли быть это не Sandisk, а китайский контрафакт? Кроме этого, Вы неправильно считаете количество переписываний секторов при записи по кольцу. Если не говорить карточке при стирании файла, что место у нее свободно (что FAT не умеет делать, это только EXT4 в свежих реализациях и с опциями), то карточка начинает заниматься внутренними переписываниями секторов, что существенно замедляет скорость записи и уменьшает ресурс.

Нет такого понятия, как ресурс сектора. Флеш стирается блоками, а здесь все плохо: у карты 16G будет порядка 125 тысяч блоков,
а ресурс каждого - несколько тысяч записей.


Я бы проверил на ПК скорость записи. У подделки она наверняка будет сильно занижена.

Тогда лучше отказаться от ФС, создать несколько кольцевых буферов блоков данных (по количеству значений времени жизни блока данных) и размер этих кольцевых буферов сделать разным. Например нужно иметь блок_данных_тип_1 (TTL=15мин), блок_данных_тип_2 (TTL=30мин), блок_данных_тип_3 (TTL=1час). Соответственно создаём:
очередь_1 = N*4 блоков_данных; очередь_2 = N*2 блоков_данных; очередь_3 = N блоков_данных. И число N подбираем таким, чтобы был занят весь объём карты.
Каждая очередь - выравнена на целое число блоков_стирания + 1 блок_стирания.
И если частота генерации разных типов блоков одинакова, то получим равномерный износ. Без закладывания на внутренние механизмы карты.

Не всегда возможно такое. В файловой системе нет ничего страшного, если оперировать достаточно большими блоками и максимально редко.
Правда тут есть грабли:
- Нужен большой объем ОЗУ
- "Народная" FatFS не имеет развитых механизмов кэширования и буферизации (но можно свою прослойку добавить между FatFS и картой)

Зачем хороший тест, не лучше ли использовать ваш алгоритм записи.
Кстати, ускоренными тестами стоит острожнее пользоваться - может перегреваться чип и ускоренно умирать.


Отправить в sandisk серийные номера, с целью проверки на контрафактность, не пробовали?

Точно. Сильно стормозил. Флеш-то про сектора не знает.
в Интернете говорят про размер страницы флеш в карточках 8-128 килобайт, ну и с другой стороны оно еще вдруг целыми кластерами переносит, а не посекторно, опять же ограничение.

Из 10 карточек нашлись некоторые, которые компьютер видит, но не может записать. То есть то что тут мне и говорили- карты перешли в read-only, но еще определяются работают. На вид- очень медленно, скорость чтения 15 килобайт/c, причем именно если с корневой директории копировать. если внутри директории работать- то все быстрее.

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

Ну и понятно куда копать. В первую очередь кэширование FAT.


Не отправил, но собираюсь. Уже накопилось. Вдруг и ответят.

Хорошую статью нашел, там народ даже лез анализатором чтоб проверить как контроллер распихивает данные на трех флешках разных производителей. Речь про USB стики, но думаю что SD карточки не сильно другие.
Write Endurance in Flash Drives: Measurements and Analysis

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

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


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

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

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

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

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

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

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

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

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

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

Не факт.
Почему Вы думаете что переназначение по износу делается на уровне блоков стирания, а не на уровне страниц?
Имхо: вполне возможно что карта имеет массив логических страниц, переназначаемых на физические страницы. Когда вы даёте команду "запись в страницу" и контроллер определяет что "поверх" запись выполнить нельзя, то он будет метить физ.страницу, связанную с данной логической как "грязную". И назначать для данной физ.страницы пустую (и неназначенную) страницу внутри какого либо блока. И стираться блок будет только когда всего его страницы "грязные". Естественно тогда необходима или периодическая или по необходимости "сборка мусора", когда блоки содержащие мало физ.страниц связанных с лог.страницами, и много "грязных" страниц и ни одной пустой: все связанные страницы будут перемещены в свободные страницы другого блока, а данный блок будет стёрт.
Тогда при записи FAT пишутся и изнашиваются только занимаемые ей страницы.


Какой "хвост блока"? Блок весь разбит на страницы, чтение/запись на карту выполняется страницами, а значит для карты всё что внутри страниц - полезные данные. И размер блока ведь кратен странице, так что "хвоста" быть не может.


Откуда Вы знаете какое начальное состояние ячеек флешь? Может там FF, а может 00.

Это только предположение. Просто если оно верно, то мои теоретические расчеты похожи на мою реальность (40 записей секторов в секунду убили флеш за пару месяцев.
Если говорить про страницу, а не про стираемый блок страниц, то ресурс должен быть примерно в сотню раз больше, что не подтверждается моей практикой.

Я с Вами полностью согласен, используемые алгоритмы сложнее (очень неплохо несколько вариантов описаны в упомянутой мною статье). Я просто хочу хоть как-то прикинуть, на сколько чего я должен выйти по записям, если мне нужно, например, 3 года жизни этой карточки.
Я думаю, что самым правильным будет если я буду считать число "длинных записей" (многосекторная запись), при условии что эта запись не выходит за границы страницы или стираемого блока (нужное подчеркнуть).

Кстати, наконец-то проверил карточки на скорость. Получил скорость записи около 31 МБ/c и чтения 73 МБ/с, вроде бы неплохо (нужно софтинку менять, у этой экран под малые скорости заточен):
Нажмите для просмотра прикрепленного файла

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

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

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

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

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

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

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

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

Предложенный Тест_1 как раз и нужен для выяснения этого обстоятельства.
Например в статье Wear Leveling от "Micron" пишут, что выравнивание может быть статическим или динамическим. В первом случае равномерно изнашиваются все блоки, во втором только часть.
Тест_1 может показать 1000 записей (для динамического выравнивания), или 125К х 1000 (для статического).
Тест_2 покажет 125К х 1000 для стат. и динам. выравнивания, или 125К для динам. в случае дорогой подделки, или просто 1000 для недорогой.
Сравнив результаты двух тестов мы и определим, какой вид выравнивания применяется, и что делать.

Всё ИМХО, ничего не навязываю, с интересом слежу за обсуждением

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

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

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


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


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

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

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

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

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

Я только уточню, что карточка должна быть не отформатирована, а стёрта командой Erase (хоть на заводе, хоть своими силами).

Идея двух тестов основана на следующем. Есть разница между статическим и динамическим выравниванием. При статическом идёт равномерный износ всех блоков, и это круто - но он применяется в дорогих приложениях, типа SSD-накопителей (при том что ресурс записи у них обычный: 2000-3000 циклов на блок).
А при динамическом - происходит износ только тех блоков, где нет данных (где после Erase ещё не было Write_Data).

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


Может быть. Например в английской Вики (статья про WEAR LEVELING) пишут, что чаще всего, у контроллера карты есть своя флешь, с ресурсом перезаписи 100.000+.