Автор Тема: [решено] Transcend V85 16 GB testpoint-восстановление и модернизация  (Прочитано 20518 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Bовка

  • Пользователь
  • **
  • Сообщений: 13
Transcend JF V85 16GB старая (2008года)

Цитировать
Volume: K:
Controller: Alcor AU6983/AU6984
Possible Memory Chip(s):
  Samsung K9MDG08U5M
  Samsung K9PDG08U5M
  Samsung K9HCG08U1M *2
Memory Type: MLC
Flash ID: ECD755B6 78EC
Flash CE: 4
Flash Channels: Single
Chip Code: 0xBB07
Chip F/W: 290C
Group: 84
VID: 058F
PID: 6387
Manufacturer: JetFlash
Product: TS16GJFV85
Query Vendor ID: JetFlash
Query Product ID: TS16GJFV85     
Query Product Revision: 8.07
Physical Disk Capacity: 16678649856 Bytes
Windows Disk Capacity:  494931968 Bytes
Internal Tags: AXWR-S832
File System: FAT32
Relative Offset: 4096 KB
USB Version: 2.00
Max. Power: 100 mA
ContMeas ID: C51C-05-00
Microsoft Windows 7 SP1
------------------------------------
...
Program Version: 7.7.0.510

Контроллер AU6984
Память K9MDG08U5M бутербродом
Восстановлена по обычной метродике: замыкание ног 29-30 флеша и форматирование в AlcorMP090515

Флешка 2008 года и умирала раза три с периодичностью ~год, но вот она умерла и  AlcorMP отказался её форматировать по причине неправильного FID

VID, PID

 Честно говоря удивлён что люди, которые разбираются в флешках на атомном уровне, описывают сам процесс testpoint как-то «неправильно» принципиально, хотя фактически всё работает, но иногда очень рискованно. Хочу описать свой опыт, может быть на сайтах скорректируют статьи чтоб они отражали сам процесс того, что происходит при testpoint.
 Потратив полдня и перечитав всё, я вместо короткого варианта восстановления (на тот момент я уже разобрал её), решил найти способ восстановления без вскрытия, надо было «всего лишь» заставить AlcorMP не обращать внимания на VID, PID и указав тип FLASH-памяти отформатировать, но он категорически отказывался, даже свежие версии в которых «типа есть» игнорирование VIDPID с активной кнопкой START просто ничего не делали при её нажатии. Попробовал изменить PIDVID с помощью Alcor VIDPID Rework, но опять был послан. Тут может справилась бы какая-нибудь FCMPTool, но я уже устал надеяться на чудо, ребята, которые модернизируете эти тулзы, научите игнорировать все эти ID, когда очень надо, пожалуйста. Остался только testpoint.
 Опишу, что происходит при testpoint в моём случае. На производстве при первом включении флешки (плата с микросхемами) контроллер видит сброшенный флаг After_Production, выдаёт предустановленные в firmware параметры(идентификатор контроллера, VID, PID, FID) "заготовки" для работы сервисных утилит и ждёт параметры конфигурации конкретного производителя (теже VID, PID, тайминги и т.д.) из USB, сохраняет их в себе или FLASH-памяти, выставляет флаг After_Production. Теперь при каждом включении, видя взведенный флаг After_Production, он читает параметры конфигурации из себя или FLASH-памяти. Если из-за чего-то эти данные повредятся, то контроллер будет инициализирован неправильно и может искажать информацию/зависать, хотя должен бы обнаружить ошибку CRC конфигурации и сообщить об этом. В моём случае вся область конфигурации была FFFF и контроллер честно её выдавал: Generic Disk, 2048GB и т.д. Так вот подавая логическую 1 на определённую ногу контроллера, которая зависит только от программиста firmware, мы сбрасываем флаг After_Production  (обычно только до выключения питания) и контроллер видя, что это первое включение не инициализируется повреждённой конфигурацией и зависает, а прикидывается "заготовкой" и ждёт её из USB. Вот как изменились мои VID, PID

FID

Сервисные утилиты могут работать.
 Теперь о том как правильно подавать эту логическую 1 (+3,3В) на ноги контроллера или FLASH-памяти. Нельзя подавать напрямую +5В, как это предлагают некоторые, в этом случае контроллер и FLASH-память не сгорают только из-за запаса прочности, которого может и не оказаться. Лучше всего замыкать ноги или подавать +3,3В через резистор 1-10кОм, в этом случае не искажается информация на шине данных, а контроллер читает FID FLASH-памяти и не перегружаются микросхемы. Но подавать +3,3В отдельно на ноги перебором (благо их всего 8) имеет смысл лишь когда неизвестно на какую именно, гораздо проще просто замкнуть две известные ноги и уж точно не надо лезть под BGA корпуса, когда достаточно замкнуть эти ноги на контроллере. Убрать напряжение с ноги надо после её опроса контроллером, по идее это через пару миллисекунд, но лучше дождаться когда устройство появится в Диспетчере устройств или через 2-3 секунды.
 Так же хочу рассказать, как устранить эту особенность внезапного умирания Transcend V85 и ранних ревизий флешек на базе AU6980-85. Я заметил что флешка дохнет когда извлекается небезопасно и когда плохой контакт USB порта, так как я её разобрал, то решил разобраться в чём же дело, благодаря схемам увидел такую строчку в Reference Design ver_1.5.9 : C4, C9 has been changed from 2.2uF to 4.7uF, а в версии 1.2 эти конденсаторы вообще равны 1мкФ и 0,1мкФ (!), сравнив понял, что надо увеличить С4 и C10(!) до 4.7мкФ
Так как нумерация компонентов на плате не совпадает со схемой, а разбираться и впаивать такие мелкие детали проблематично, то лучше припаять конденсатор порядка 10мкФ (лишь бы в корпус влез) к +5В и GND прямо на разьём USB

После этих изменений наверняка можно забыть о внезапной смерти.
Сторона памяти

Testpoint Flash Drive Information Extractor

Transcend JFV85 16GB Flash Drive Information Extractor



Хочу поблагодарить nat27 DavodAmirajam и сайты flashboot.ru usbdev.ru
« Последнее редактирование: 20 Ноября 2013, 20:35:43 от Bовка »

nat27

  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2857
Привет!

Чего то я не понял про новую методику сброса. Вначале вы сообщаете что применили стандартный метод замыкания ног контроллера по шине данных. А затем говорите про другой метод, подачей (+3,3В) на ноги контроллера или памяти через резистор. Не могли бы вы уточнить в деталях, конкретно номера ног и всю методику, очень интересно найти новые способы сброса контроллера.

Bовка

  • Пользователь
  • **
  • Сообщений: 13
Доброе утро. Только не надо на вы :) методика старая, просто начитавшись как иногда рекомендуют, людям далёким от электроники, замыкать +VUSB на ноги контроллера (иногда сразу несколько) или во что б это не стало «мучать» именно ноги памяти и иногда люди BGA/LGA корпуса выпаивают вместо того что б ноги контроллера замкнуть, я был в шоке насколько это рискованно, а ведь легко делается правильно и безопасно. Дело в том что контроллеру надо увидеть +3,3В на определённой ноге (в моём случае это нога 44 FMDATL0), и самое безопасное это подать + через резистор на эту ногу, в этом случае контроллер вообще не перегружается (можно этот резистор отключить хоть через час ) и в тоже время как только он расчехлится что это тест-моде (порядка 10мс), он пойдёт работать дальше, наверняка прочитает FID памяти, а там в случае «грубого» замыкания информация исказится, у меня был FID=0xEC,0xD7,0x57,0xB7,0x78 видно «слипшиеся» x7 x7 x7, так как я просто замкнул ноги 43 и 44 контроллера (они дорожками соединены с ногами 29, 30 микросхемы-памяти соответственно), а в случае с резистором контроллер или память, когда будет выдавать FID, его легко «перетянет» и информация на шине не исказится. Плюс через резистор можно не париться с правильными 3,3В а подавать удобные 5В, всё равно ток малюсенький и напряжение на ноге ограничится внутренними защитными диодами контроллера. Но когда точно знаешь какие ноги надо замыкать, то конечно намного проще замкнуть две соседние ноги, стресс для контроллера и памяти незначительный и риска никакого.
Прочитав твоё руководство, DavodAmirajam, usbdev.ru про testpoint, я так и не увидел саму суть что происходит с контроллером и мне показалось авторы тоже только подошли к сути, описали как войти в этот режим, а дальше как будто чудо, с прошивкой что-то происходит и контроллер прошивается. А самого принципа что в нормальном режиме контроллер инициализируется с флеш-памяти, а в testpoint он прикидывается заготовкой и инициализируется из своего firmware и принимает всё с USB, а память можно хоть отпаивать – ему она тут для старта не нужна, вот этого всего я не увидел. Эта информация для восстановления практического значения не имеет, но для диагностики и понимания самого процесса спецам, думаю  должна быть интересна. Тем более принцип активизации этого служебного режима (testpoint) подобен во всей электронике – в мобилках, планшетах, в микроконтроллерах так обычно bootloader активируется. Статью писать смысла нет, а вот остальные, если сочтут эту информацию правдоподобной, то может и подправят свои статьи.
« Последнее редактирование: 12 Ноября 2013, 10:43:49 от Bовка »

nat27

  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2857
Первый раз слышу чтобы где то предлагали +5в напрямую подключать к контактам шины данных при сбросе контроллера, всегда замыкали контакты шины данных между собой токопроводящим инструментом. Суть данного действа - заставить контроллер выполнить подпрограмму внутреннего сброса по ошибке на ШД. У некоторых контроллеров есть специальные тестовые пины(ножки) при активировании которых (чем и как пишут в даташите) исполняется команда внутреннего сброса.

Контроллер инициализируется из внутренней памяти, внешняя память для инициализации(контроллера! речь не идет о системе носителя) не нужна, также как и VIDPID хранятся во внутренней памяти.

Если подтянуть внешним резистором +5в одну из линий шины данных, то это не даст требуемого эффекта, линия как прыгала из 1 в 0 и наоборот, так и будет прыгать. А вот когда мы закоротили между собой две ноги, то выставив на одну ногу лог.0 а на другую лог.1 контроллер считает обратно две линии в состоянии лог0. что будет интерпретировано как ошибка и будет запущена программа сброса контроллера.

Похоже что вам необходимо самому немного разобраться с принципами процедуры сброса и процессами, происходящими при этом, а не рекомендовать авторам править свои статьи.
« Последнее редактирование: 12 Ноября 2013, 12:21:36 от nat27 »

Anatolij

  • Модератор
  • Ветеран
  • *****
  • Сообщений: 2673
Цитировать
Дело в том что контроллеру надо увидеть +3,3В на определённой ноге
Шина данных и так подтянута через резисторы на питание, т.е. логическая единица там и так будет.

Bовка

  • Пользователь
  • **
  • Сообщений: 13
К сожалению, вижу я тебя чем-то рассердил, извини. Советует подавать +5В, например, тут и тут, просто видно что человек понимает, но советует опасные вещи.
Активацию этого сервисного режима в datasheet на контроллер AU6984 я не увидел и думал что вывод определили методом тыка.
У контроллеров есть flash-память программ в которой хранится firmware, у некоторых типов контроллеров есть eeprom-память для хранения данных (конфигурационные данные) иначе они самопрограммируют свою flash-память программ выделяя последнюю страницу памяти под конфигурационные данные. Но во флешках повреждаются только параметры конфигурации, но firmware контроллера не повреждается - значит хранятся в разных "памятях" иначе повредилось бы всё, может инициализация лежит в eeprom, но по моему опыту в контроллерах такого типа её там нет и даже если есть, с чего ей повреждаться? контроллер параметры инициализации записывает только при первом включении и больше никогда туда не пишет, а только читает. А вот если он хранит параметры конфигурации в внешней микросхеме flash-памяти (как это часто делают), то есть большой шанс что эти данные повредятся при нестабильном питании так как к этой памяти контроллер часто обращается в режиме записи (правда не в область хранения конфигурации) и если конфигурация хранится рядом таблицей разделов, то повредится всё, что в принципе часто и наблюдается (хотя может быть это из-за повреждённых таймингов чтения память не читается корректно). У меня например вся память конфигурации бала забита 0xFF из-за чего и была вся проблемма, а заполнение flash-памяти 0xFF это обычное дело, так как она пишется страницами (блоками КБ) и контроллер не может модифицировать несколько байт в середине стреницы, то модифицируется память следующим образом: считывает страница в буфер (не страничного типа)- в буфере модифицируются нужные байты - стирается страница в flash-памяти (а чистая flash выглядит как 0xFF, 0xFF, 0xFF...) - страница из буфера записывается обратно в flash-память (физически записываются нули). Как видишь обращение к  flash-памяти на запись частое и вероятность получить чистую страницу в flash есть, в то же время вероятности повредить внутреную память контроллера практически нет, так как он не пишет в неё (зачем?). Ну и моя страница конфигурации выглядела, как я сказал в начале, так:

Цитировать
Если подтянуть внешним резистором +5в одну из линий шины данных, то это не даст требуемого эффекта, линия как прыгала из 1 в 0 и наоборот, так и будет прыгать.
Дело в том что нам это и надо, она "прыгает" сама когда это надо и когда она настроена как выход, а когда контроллер считывает состояние testpoint, то она настроенна как вход и притянута к + резистором, "дёргать" её не кому.
Цитировать
А вот когда мы закоротили между собой две ноги, то выставив на одну ногу лог.0 а на другую лог.1 контроллер считает обратно две линии в состоянии лог0
Вот тут ты прав, но с точностью до наоборот, контроллер считает обратно одну линию (вторая сконфигурирована на выход) и она будет равна 1, что будет интерпретировано как сброшенный After_Production - признак первого запуска.
Дело в том что я это всё не выдумываю, повторяю многие микроконтроллеры широкого применения читают свои определённые ноги для запуска bootloader и всегда производитель рекомендует "подтянуть" эту ногу, подразумевая через резистор, практически никода сигнальные ноги не садятся на шины питания напрямую.
Ладно пойду немного разобраться с принципами процедуры сброса, хотя как-то умудряюсь писать программы под микроконтроллеры.
Цитировать
Шина данных и так подтянута через резисторы на питание, т.е. логическая единица там и так будет.
Не затруднит ли указать номер резистора на схеме Reference Disign которым подтянута хоть одна нога шины данных? (pull-up и push-down резисторы обычно можно включить программно внутри контроллера)
Всего хорошего.
« Последнее редактирование: 12 Ноября 2013, 13:50:05 от Bовка »

nat27

  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2857
Вовка мы здесь проводим эксперименты по подъему флешек, поэтому личный опыт приветствуется, спасибо что поделился своими наблюдениями, у тебя флешка заработала и это главное. Спасибо за слова благодарности в наш адрес.   

nat27

  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2857
Вовка Так может поэкспериментируеш с контроллерами ALCOR, включая разаработку небольших утилиток если надо. Может получится какая новая методика сброса. На глубинном уровне я с контроллерами дел не имел, всех ньюансов работы не знаю. Утилиты к контроллерам Alcor уже давно идут зашифрованные, ничего, кроме интерфеса перекрутить нельзя, а как хотелось бы. Есть проблемы непонятные с утилитами, по неизвестной причине алькоровцы  заблокировали восстановление некоторых типов памяти в двухканальной конфигурации, хотя флешки с контроллерами предыдущего поколения восстанавливались нормально. Если бы можно было присвоить контроллеру другой ChipCode или в утилите добавить распознавание новых кодов, то это было бы огромной помощью. Маловероятно что можно сменить код контроллера, похоже он в пзу, но мало ли что, может можно написать драйвер, который будет подставлять другой код контроллера. Если есть чем помочь, сообщи, это только пойдет на пользу всем. Любым реально работающим методам восстановления флешек буду только рад.   

Bовка

  • Пользователь
  • **
  • Сообщений: 13
На самом деле с практичиской точки зрения в моём сообщении гораздо важнее информация о добавлении (припаивании сверху/параллельно) конденсаторов на 4,7мкФ потому как в Reversion History она попала не просто так, а это производитель был вынужден изменить Reference Disign из-за рекламации, а эти конденсаторы стоят именно на питании 1,8В и 3,3В и проблемы с питанием наиболее вероятная причинаповреждения flash, во время записи если флешку выдернули из разъёма, то зараяда слабых конденсаторов может не хватить на то что бы микросхема флеш-памяти записала страницу из буфера на очищенную страницу. Эти конденсаторы наверняка решают эту проблему, но для того что бы их запаять надо уметь неплохо паять. Я, например, делал ЛУТом отладочную плату с контроллером в QFP176 и его туда запаивал, но тут вижу будет тяжело влепить эти конденсаторы, наверное был изменё и дизайн печатной платы под больший типоразмер. Вот эту информацию если б вы распространили владельцам AU6980-86 старых ревизий плат до 1.5.9, то может они предупредили свой головняк в дальнейшем.

nat27

  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2857
Дак флешки 6986 в далеком прошлом, сейчас все поменялось, основная используемая память во флешках это TLC, что влечет за собой гораздо большие токи(пиковые) при записи, вплоть до максимально возможных по требованиям USB2.0 в 500ма для 64-128ГБ, например.

Основная серия флешек идет на 6998 контроллерах у алькора и в этом секторе: 6998+TLC больше всего проблем. Утилиты собираются с жесткой привязкой по составу прошивок, модернизировать не удается, ну кроме интерфейса, что сути не меняет. Очень много проблем с неправильно работающими контроллерами по причине горячего отключения или фейковой памяти и в 70% случаев контроллер надо "сбрасывать". Поэтому есть острая необходимость в безопасной методике сброса.
« Последнее редактирование: 12 Ноября 2013, 14:33:23 от nat27 »

Bовка

  • Пользователь
  • **
  • Сообщений: 13
nat27, дело в том что это очень сложно на эти контроллеры нет фактически ничего, datasheet и тот содержит только распиновку и эл.хар-ки, единственный способ это снифать USB и пытаться реверсить (узнавать команды, регистры) протокол обмена прога-контроллер, а если он вдруг окажется шифрованным - то дело табак. Нового ничего не придумаешь, иного чем заложил производитель в firmware не получишь и в лучшем случае, если отреверсить  интерфейс прога-контроллер, то придётся делать свою прогу которая будет слать эти же команды, только без ограничения и возможно...
Целесообразней наверное попататься "подружить" старую нешифрованную прогу с новыми контроллерами, путём подмены идентификаторов в файлах или в проге,  но думаю вы это уже пробовали и реальность такого варианта тоже, чуть меньше нуля. Ни памяти не контроллеру невозможно запрограммировать другие идентификаторы, только попытаться подменитьидентификатор чипа в старой программе, что б она думала , что например идентификатор 0xCF02 принадлежит AU6983, а в папку драйверов AU6983 закинуть драйвера от AU6998N (но они тоже наверняка шифрованные, хотя по виду определить можно), короче я такой примитив ща рассказываю, вы наверняка это пробовали, я к этим флешкам только несколько раз подлазил в сервисной программе кнопочку ткнуть, а вы тут уже на них зубы сточили, что я тебе могу рассказать ?  ;D

nat27

  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2857
Так отож, все шифровано, а по другому и трудно представить, компания держит все за семью печатями. Большое счастье что есть китайские товарищи, которые хоть чемто делятся, с алькорами еще более менее работать можно, а вот сандиск(о ужас) даже нет сервисных утилит, как и всяких даташитов, схем. Не могу представить, как можно так шифроваться, похоже что чипы контроллеров сандиск никому не отгружают насыпом и, видимо весь процесс производства флешек замкнут глубоко под землей и китайци там не работают :) .
 Какие уж там зубы, так, голый энтузиазм, здесь свежий взгляд со стороны не помешает. Рассказал бы ты, например, о новых "принципах активизации этого служебного режима (testpoint)" а мы бы проверили и взяли на вооружение. 

Bовка

  • Пользователь
  • **
  • Сообщений: 13
nat27, дай ссылку на эту шифрованную оригинальную прогу Alcor не MD т.е. оригинальный для AU6998, просто я смотрю на прошивки (98_xxx.bin) для AU6989, которые в AlcorMP10014T_20120824 они модулями нешифрованные, т.е. если б производитель шторился, то наверное их бы шифранул.
Перевод контроллера в этот testpoint режим нужен только тогда , когда прога до него не может достучаться, потому что он в програмно-мёртвом состоянии  или отказывается с ним работать типа "рожей не вышел", а для подцепиться прогой которая его не поддерживает этот режим не поможет. А когда прога к нему может подцепиться, она его сама в нужные режимы переводит. Т.е.програмно убить контроллер, затолкав в него кривую прошивку невозможно, полюбому воскресишь. У вас в практике были случаи когда "убив" его не той прошивкой, вы не могли б его поднять?
Да я ж говорю способ не новый, он же единственный, просто он безопасный и после того как контроллер опросил эту ногу, резистор вообще не влияет на работу, но снять его надо иначе контроллер опять "болванкой" прикинется при следующем подключении.

Bовка

  • Пользователь
  • **
  • Сообщений: 13
Вот меня совесть укусила, что я рассказываю про этот testpoint с резистором, а сам сделал замыканием ножек, решил проверить теорию и подал 5В на 44 ногу AU6984 через резистор 5,1кОм

воткнул в USB и получил Generic с VID/PID заготовки в диспетчере устройств, в диспетчере дисков дисковый накопитель без носителя

 убрал резистор, ничего не изменилось, передёрнул флешку и получил назад свой Transcend с дисками и файлами

Как видно контроллер игнорирует флеш-память, или опрашивает только её FID, и отдаёт минимальное количество данных, видимо для того что б утилита ему собрала прошивку под конкретный набор: контроллер + flash-память, просто в папке прошивка лежит модулями: ядро, модули под различные микросхемы памяти, наверное ещё модули для чего-то. Я тут подумал, у вас же были случаи, что флешка становилась в два раза худее, это наверное, по каким-то причинам, утилита брала для флешки работающей в двухканальном режиме, модуль ядра одноканального режима, а если подменить модуль ядра одноканального режима модулем двухканального, просто переименовав его файл именем одноканального модуля, утилита соберёт прошивку двухканального режима и вот она флешка на полный обьём и коммунизм во всём мире, короче догадка на догадке ;D
А, совсем забыл, тут товарищ предлагает щуп  для ножек микросхем, по последнему слову нанотехнологий, может и баян, а может и пригодится.

nat27

  • Глобальный модератор
  • Ветеран
  • *****
  • Сообщений: 2857
Оригиналы беру здесь, модифицируется только то что доступно, а это не так уж и много, интерфейс, некоторые ключи в AlcorMP.ini, языковые тексты. Поэтому можно смотреть и модифицированные, прошивки и код программ не правится.
У меня есть флешка (ChipCode 0xE304)AU6998AN + Dual Micron L74A (см. в правилах раздела алькор фото) убитая с помощью AlcorMP, её можно восстановить только в одноканальном режиме к половине объема ввиду ничем не объяснимым ограничением утилит. Предполагаю что косяк намерянный в утилите. Причем есть другая флешка на AU6990 и двухканальным микроном, с ней проблем нет. AlcorMP10014 очень хорошая утилита, последняя из нешифрованных, к сожалению (ChipCode 0xE304) не берет, хотя другие контроллеры 98 группы AU6998 обрабатывает легко, внедрить в эту утилиту ChipCode 0xE304 вместо любых других моя давнишняя мечта, но не знаю как.
Про сброс контроллера все так, нужен он только когда контроллер в неадеквате. Утилиты могут не поднять флешку если нет прошивки для данного типа памяти или не знает чипкод контроллера. Или если заблокировано в утилите некоторые ситуации - например дуал конфиг, которого, кстати не бывает на TLC памяти и утилиты только для TLC не работают с Dual MLC, нет обращения по H-каналу.