Стокнулся с аналогичной проблемой. UFD Transcend JF300 4GB VID_090C&PID_1000.
Контроллер SMI SM3255AA
Память Samsung K9ABG08U0A H0227 FID:[EC D7 98 CA 54 42] 32nm TLC NAND Single 2-Plane
(Они бывают разные хотя все "вроде бы одной модели" - K9ABG08U0A - и хрен Вы отформатируете "не ту" (другой FID) "не той" прошивкой. Samsung - козел.
)
ISP Version: 100403-AA-
Tester: V 2.03.21 (был первично с завода)
Page size: 8KB
Block size: 256 pages
ECC 24bit
Было 18 заводских бэд блоков.
Мать Transcend 29-7962 V1.0
Выпущена в 2010 году. Корпус типичный, см. в нете "картинки" по Transcend JetFlash 300.
При сканировании автозапуска винды флешка отваливалась и вскоре снова появлялась (что, конечно, вызывало подозрения относительно отвала разъема, которые вспоследствии не подтвердились). При отключении автозапуска - определялась и НЕ отваливалась, с нее читался каталог и некоторые файлы и папки. При чтении иных файлов или папок, аналогично. отваливалась и переопределялась. Посекторный анализ с помощью DMDE четко выявил, что, при попытке чтения определенных конкретных секторов, флашка уходит в перезагрузку (для чайников - флешка перезагружается "внутри себя", а не Ваш комп, ибо флешка это тоже "готовый спец комп", со своим процом, памятью и иными ресурсами). Некие события или данные в памяти вызывали Reset контроллера.
Контроллер может уходить в сброс и перезагрузку по двум основным причинам, точно также, как и комп. Некая программа привела в падению ядра и принудительной перезагрузке, либо некая аппаратная проблема привела к просадке питания ниже предельного уровня, сбросу проца за счет некой внутренней логики его работы (например, в случае искажения неких критических данных по шине), подаче резета на соотв ногу проца иным устройством или функциональным блоком (например, WatchDog-ом в случае, если он увидел зависание проца), Ситуация, когда "рядовое чтение" неких секторов ведет к сбросу проца, явно не нормальна. Даже если при чтении выявляются сбойные блоки, приводить к резету проца это никак не должно, есть процедуры обработки этой ситуации, да еще какие "крутые", ведь работа с NAND, в отличие от иных физических носителей, как раз подразумевает очень развитый, "интеллектуальный" defect management и wear leveling.
Если это программная проблема - значит программа кривая, точнее сказать, кривая именно данная версия или набор версий прошивки контроллера. Если это аппаратная проблема, то уж очень странная. Возможно, например, что при чтении определенного сектора происходит КЗ и просадка питания, что и ведет к резету или с флеши "внезапно" на порты проца начинает течь "гиганский" (по меркам этой цепи) ток или "шить высокое". Но вот "беда" я не могу представить себе в своем воспаленном мозгу ситуацию, которая могла бы физически вести к таким проявлениям. Если произошел некий пробой и появилось КЗ мне сложно представить себе, чтобы он проявлялось лишь при попытке чтения сектора, на который, к примеру, такое КЗ попало. Гораздо больше все это похоже на то, что контроллер в силу некого косяка в прошивке, виснет на каких то данных трансляции (их чтении или, например, перерасчете в связи с "обнаруженным" (уже 1248 разм
) бэд блоком, который он нИАсиливает.
Наиболее вероятно, что на каких-то данных он тупо виснет и его сбрасывает внутрипроцовый WatchDog. Это по нашим меркам задержка в 1-2 секунды это "типА притАрмАзил". По меркам WatchDog-а, если проц не отвечает в течение неких долей секунды, можно смело делать вывод что он завис, и завис насмерть, поск за секунду современный проц успевает выполнить тысячи и миллионы операций.
Понятно, что выяснить что происходит на практике не представляется возможным, поск для этого необходимо иметь отладочный комплекс для данного проца и трассировать его работу (+очень желательно еще иметь исходники, ибо отлаживать подобные проблемы в "чужеродном" асме Intel 8051, мягко сказать, весьма трудозатратно. Сделать подобные "манипуляции" на практике с применением разумных трудозатрат и очевидной, в т.ч. экономической отдачей может только производитель контроллеров-прошивок, что он, очевидно, давно и сделал, поск, как следует из поиска, подобная проблема встречается, похоже, лишь на SM3255AA и, видимо, лишь на определенных версиях прошивок.
Вытащить данные с такой флешки не так сложно, как "тут малюют". Для этого нужно просто... у. трудиться, а не слюни распускать. Есть 2 основных варианта стратегии спасения данных. 1. Слить все читающиеся сектора в образ или на другой носитель и потом разбираться в том, что физически уцелело там. 2. Сдать флешку мастеру по восстановлению данных, заплатить некие деньги, и подождать, пока он "сдует" NAND (благо все носители с подобной проблемой, вроде как, не "монолиты"), сольет его содержимое на спец программаторе, натравит спец программу для разбора "чехарды" на NAND и вытащит все уцелевшие данные.
Тем у кого количество сбоев зашкаливает или локация сбоев попала на некие структуры файловой системы, что сильно затрудняет восстановление, либо, кроме как стонать и плакать, они ничего "не умеют" - можно порекомендовать стратегию 2. Остальные могут спокойно, терпеливо и кропотливо вычитать все читающиеся сектора с помощью DMDE, Мне хзватило пары часов чтобы слить все что нужно и вытащить файлы ([чужие] доки, фото, музыку объемом на 3/4 флешки) с помощью R-Studio. Почти все сбои попали на "мусор". Кому-то повезет меньше и он может засеть на целый день или даже на неделю, возможно даже безуспешно либо со "скромным успехом".
Общая стратегия вычитывания "штатными" средствами (без аппаратуры) проста и незатейлива. Берем DMDE, пытаемся оценить что "работает", что нет. Потом "тупо" пытаемся слить все сектора, начиная с 0-го и до конца в файл-образ на винте. DMDE начинает читать и копировать сектора в образ. На каком-то секторе он затыкается, флешка перезагружается и пытаться нажать Retry бесполезно, ибо, как отметил топикстартер выше, заново она определяется уже как (программно) другой носитель с т.з. Винды. Надо запомнить на каком секторе (блоке секторов) "сдохло", открыть диалог выбора дисков и выбрать все тот же "старый-новый" носитель заново. После этого попытаться сразу читать в районе сбойного места, после сбойного места, с определенным запасом, чтобы понять точно на каких секторах флешка падает, а на каких (уже за сбойным блоком) снова начинает читаться. Каждый раз при неудачном чтении флешка будет падать и переопределяться и каждый раз придется заново выбирать носитель и вручную задавать сектор для следующей попытки чтения. Изначально надо пытаться "прыгать гинантскими шагами" - пытаться читать весьма далеко за сбойной областью. Я успел локализовать начало участка со сбойными блоками, его конец (читая с конца носителя) и насчитать с десяток сбойных блоков внутри проблемной зоны, чередующихся снормально читающимися блоками, к моменту, когда понял, что все нужные данные успешно вытащены.
Все выявленные нормально читающиеся блоки данных необходимо скопировать в файлы на винте, с точным указанием на то, с какого по какой сектор они содержат данные. Далее из кусков нужно собрать целый образ диска заполнив недостающие блоки "нулями", т.е. файлами нужной длины, содержащими только ASCII (0), либо, к примеру, словом BAD, как это делает DMDE, когда обнаруживает битый сектор на любом носителе или копирует его на другой носитель или в образ. Необходимо это для синхронизации структур файловой системы при последующем разборе с помощью утилит восстановления данных (а может и просто все скопируется "обычным способом" при монтировании образа в качестве диска). Ошибаться с синхронизацией никак нельзя, ибо это приведет с смещению всех данных за такой синхронизацией и все попавшие туда файлы окажутся поврежденнымми при попытке их последующего восстановления.
Если Вы затрудняетесь с синхронизацией (расчетом секторов-блоков) посредством сборки полного образа из "полезных блоков", считанных с носителя, и "нулей" (нужной длины, сгенерированных Вами), просто копируйте данные с "битой" флешки на исправную (флешку или иной подоьный носитель, равного или большего объема, с которого надо предварительно слить все нужные данные). Например копируете "читающиеся" сектора с 12340 по 20000 на битой флешке в сектора 12340-20000 на "исправной флешке". Потом, например, идут сбои, сектора с 20000 по 22000 не копируете, и далее копируете с сектора 22000 по сектор 36000, которые нормально читаются, на "те же номера секторов" на "рабочей флешке". Ну и так далее. Думать и считать много не придется. В конце на "рабочей" флешке окажутся все данные, которые удалось считать и "на своих местах". В промежутках останутся старые данные, которые были на "рабочей" флешке до начала работ. Иногда это не проблема, иногда они могут сбивать с толку (как человека, так и программы восстановления) при последующем восстановлении скопированных данных с битой флешки, поск перемешаны с ними физически на одном носителе. Чтобы этого избежать, можно заранее заполнить всю емкость рабочей флешки "нулями" или тем же словом "BAD" в DMDE. Тогда после копирования на "рабочую" флешку данных со сбойной, все блоки который не были скопированы, останутся заполнеными словом BAD и их можно легко дифферециировать визуально от слитых блоков.
Вобщем, как написано выше, у меня ушло около 2 часов чтобы все нужное слить. количество сбоев было не велико, но никак не "один и не два", десятки блоков различной длины, кратной по-моему 16 секторам (NAND имеет страницы по 8KB, что соотв 16 секторам). Данную статью я писал неск дольше. С другой стороны, я прекрасно понимаю, что провозиться можно и день и неделю и более, ибо все зависит от количества сбоев и их локации, на какие, полезные или бесполезные, данные они попали. Труднее всего придется если сбои попали на критически важные структуры файловой системы (MBR/Boot/FAT/Root, какие-то каталоги с нужными файлами), которые придется регенерировать вручную или с помощью неких утилит восстановления, дополнив "из головы" недостающую информацию. В случае же, когда сбои попали на нужные Вам файлы, как раз, долго возиться, скорее всего, не придется. Вы просто с честью и достониством примите мысль о том, что эти данные Вы безвозвратно потеряли и никакими средствами Вы их уже не восстановится, в т.ч., скорее всего и с помощью профессионала тоже.
Профессионал может оказаться сильнее, разве что в том случае, когда сбоев очень много и они сильно чередуются с рабочими участками. К тому же, внутри страницы, часть данных вполне мола уцелеть, другое дело, что они в какой-то части и степени повреждены, но флешка отдает весь блок как сбойный. Но такие ситуации, когда именно на битые 8КБ попали самые нужные и "особо ценные" данные, уже больше напоминают нюансы, чем "мейнстрим". Битую "фоточку" размером в пару метров, у которой "в середине" выпало 8КБ сжатых данных, из-за чего ее "показывает" только "наполовину экрана", тупо выкинут и забудут (тем более, что восстановить ее практически нереально).
Если данные крайне важны - не морочьте голову себе и другим, сразу идите к профи (только не кому попало, ибо лохотрон просто фатально зашкаливает, есть спец форумы, там вам подскажут, кто есть ху в вашем регионе) и не жадничайте на гавноденьги. За такие работе берут 3 - 30тр, редко больше. Основная часть "крутится" около 10тр. Сегодня люди получают в среднем по 20-100тр ЗП в зависимости от региона и работы. Работы эти относятся к разряду крайне сложных (даже простые варианты), они "постоянно разные", никогда не знаешь с какой "неизведанной проблемой" столкнешься завтра, и трубуют соотв оч высокой и разносторонней квалификации (годы и десятилетия работы) и весьма тяжелых трудозатрат (даже при наличии таковой квалификации, бошка реально трещит, когда собираешь "мозаику из рассыпавшейся ФС", мало кто из профи делает это сегодня вручную, здоровье дороже).
Когда-то люди без лишних разговоров платили среднегодовую ЗП за неделю-две работы. И это не казалось дорого ни заказчикам, ни исполнителям. Заказчиками почти всегда были организации ибо именно у них "водятся" критически важные данные. Сегодня, когда основная часть заказчиков - частные лица со своими "фоточками", которые "очень ценные", но смотрели их последнй раз в 2005 году, начинают крутить мозги (обычно не мне, ибо я "там не летаю") за какие-то вобщем-то смешные деньги, на которые не всегда и эту неделю то и проживешь, которую надо затратить на работы. Это несерьезно и неуважительно и к заказчику и к исполнителю. За "дешевыми" ценами - велкам на рынки - там торг уместен, и в магазины дискаунтеры, там "скидки до 70 или 90%" и иной "теплый-ламповый" лохотрон по продаже "ненужных вещей" по "конским ценам". Если труба с деньгами, а на Руси бедность не порок, и не надо никого обижать и унижать, прилагайте собственные усилия. Разбирайтесь и делайте своими силами, ведь никто ничего особо не скрывает, а отличный инструментарий, о котором не могли и мечтать в далекие годы, доступен во фри. Очень сложно (в каких-то случаях) - ищите кто Вам поможет и как мотивировать какого-то профи. Кому-то может огрод вскопать надо, всяко бывает. Везде люди живут. Мне на западло помыть полы человеку, который мне искренне помогает и не унизительно ни разу. Главное чтобы было взаимное уважение, уважение к труду и честность, тогда все работает как надо.
В данный момент я озабочен как форматнуть данное творенье. Цена ему даже до 100руб не дотягивает ибо за 100р дают "новую в магазе" на том же говноTLC, однако профессиональная гордость (тут, наверное, даже гордыня) покоя все равно не даст (и это правильно). Мало того, что указанный FID нифига не прописан в утилитах с поддержкой SM3255AA (прописан для SM3255AB и новее), так еще и после его прописывания утилиты виснут на форматировании (уже ноги NAND коротил после этого) или вылетают с ошибкой с одновременным отвалом-переопределением флеши (т.е. происходит точно такой же сброс проца при каких-то технологических операциях внутри флеши, хотя перед этим прелоудер, прошивка. и CID успешно заливаются в начале процесса). Мало того, циклический отвал-переопределение начинаются сразу же после попытки поставить соотв галку напротив Factory Driver, хотя никакого автозапуска при этом может не происходить. При ручной установке Factory драйвера - не отваливается, однако, носитель почему-то не определяется утилитой, хотя только что мог определяться через стандартный виндовый драйвер. Вобщем бардак (в китайских утилах) и полтергейст. Прошивка контроллера у меня той же версии, что и стояла, она вроде как, последняя под данный контроллер, она то и вызывает подозрения. Надо поглядеть более старые, наверное в комплекте старых утилит. Выше народ писал, что где-то есть таки рабочие методы восстановления с этой проблемой, но ссылок не привел, "будем поискать". Сумею сделать, дополню...