Поиск

[Bовка]

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

[nat27]

Привет!

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

[Bовка]

Доброе утро. Только не надо на вы методика старая, просто начитавшись как иногда рекомендуют, людям далёким от электроники, замыкать +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 активируется. Статью писать смысла нет, а вот остальные, если сочтут эту информацию правдоподобной, то может и подправят свои статьи.

[nat27]

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

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

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

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

[Anatolij]

Дело в том что контроллеру надо увидеть +3,3В на определённой ноге

Шина данных и так подтянута через резисторы на питание, т.е. логическая единица там и так будет.

[Bовка]

К сожалению, вижу я тебя чем-то рассердил, извини. Советует подавать +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 резисторы обычно можно включить программно внутри контроллера)
Всего хорошего.

[nat27]

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

[nat27]

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

[Bовка]

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

[nat27]

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

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

[Bовка]

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

[nat27]

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

[Bовка]

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

[Bовка]

Вот меня совесть укусила, что я рассказываю про этот testpoint с резистором, а сам сделал замыканием ножек, решил проверить теорию и подал 5В на 44 ногу AU6984 через резистор 5,1кОм

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

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

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

[nat27]

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

[nat27]

Да при первом подключении любая флешка и без закоротки видна с пустыми полями и 0 объемом, контроллер может быть совсем не таким как по маркировке, но это утилита так его кличет. Но это надо поэкспериментировать, 44-нога несет какуюто хитрую функцию у контроллера, почему именно её надо единицей определять?
А после исполнения утилиты все поля заполнены, это и понятно, утилита постаралась, в поле Firmware version отражается код утилиты AlcorMP, у каждой утилиты он свой, по этому коду можно понять чем шили флешку.

Ввиду большого количества догадок и вопросов тркебующих проверок предлагаю перенести общение в личную почту здесь, ибо все это может вылится в большой объем неоднозначной информации.

[Bовка]

44-нога несет какуюто хитрую функцию у контроллера, почему именно её надо единицей определять?

Блин я вчера сутки не спал, расписывая свой опыт и процесс в общем и частностях, и всё ради того чтобы ты мои посты по диагонали прочитал? Я получается вчера только доказывал что не мимокрокодил в ролях, а чо та соображаю? Я понимаю что основной контингент сюда забегает без опыта и создаёт 100500 тему вида ПАМАГИТЕ, хотя конкретно его баян рассусолен первым постом, но я надеялся что всё таки мой опыт и знания не пройдут незамеченными.

Так вот подавая логическую 1 на определённую ногу контроллера, которая зависит только от программиста firmware, мы сбрасываем флаг After_Production  (обычно только до выключения питания)

Хоть Alcor и продаёт Evaluation Kit и SDK за $250 (я удивлён что его нет в доступе, деньги-то требуют за железо), уверен что firmware пишут именно Алькоровцы (и сделали они его как фитчу своих контроллеров) и именно они наделили эту ногу этой функцией, а не Трансцендовцы например (тогда хрен бы мы этот режим имели, потому как производитель в него не войдёт, нету же самих testpoints). Скорее всего этот режим подобен bootloader`y и лежит в ROM, которое вообще хрен убьёшь, это был бы идеальный вариант для всех, а так обычно и делают. Тогда странно, что упомянуто только ISP-программирование, хотя обновление по USB особо упоротые могут тоже назвать In-System.

А после исполнения утилиты все поля заполнены, это и понятно, утилита постаралась...

Утилита не исполнялась (не форматировала), я её только для информации запустил. Я этот эксперимент провёл что б показать что контроллер работает в двух режимах (пользовательский с VID/PID заказчика, и заводской до программирования с соответствующими VID/PID, также у памяти спрашивается только FID, а в нормальном всё работает и не повредилось) и переключается именно этой ногой, а да, ещё и номинал резистора в 5к не слишком большой и переключение происходит надёжно, и нет искажения информации на шине данных (все 8 младших бит FID правильные, а не «залипшие» к 0 или 1).

У меня есть флешка...убитая с помощью AlcorMP

Имел ввиду несколько другое – возможно ли запороть прошивку контроллера (например «залив» пустой .bin) так чтоб он вообще не мог выполнять testpoint, это б свидетельствовало о том, что этот режим лежит в flash контроллера, а не его ROM. Подозреваю, что можно пытаться «скармливать» контроллеру любые прошивки и в случае чего воскрешать его из любого состояния переводом в тест-режим и последующим форматированием, лишь бы аппаратно был целый, а аппаратно себя контроллер не может убить никак, какая б прошивка не была.

предлагаю перенести общение в личную почту здесь, ибо...

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

Про сброс контроллера все так, нужен он только когда контроллер в неадеквате.

Я тут подумал (вообще меня куча идей посетила, но я половину уже забыл) что форматировать флешку лучше всегда через него, это предупредит множество проблем, так как флешка выглядит как только с завода, единственное что останавливает, так это разборка корпуса и сложность самого подключения (кстати подключаться надо «правильно» через резистор, что б не было искажения информации на шине данных, а то это породит новые грабли с неправильным FID, может из-за этого твоему 32GB нормальную прошивку не дают), ну и программы разных производителей должны жрать «несвои» флешки, например, OnLineRecovery должен восстанавливать NONAME или SanDisk какой, лишь бы контроллер и тип флеша совпадал с «фирменными». Или он и так восстанавливает всё подряд ?
Посмотрел я по-диагонали ваши программы и вижу что прошивки нормальные, нешифрованные. Так что смысла шифровать программу и не шифровать firmware никакого. Может вы приняли за шифрование то, что раньше файлы ресурсов лежали текстом, а потом их стали сжимать или вы их анализировали? В OnLineRecovery вообще нихрена нет, или я не увидел, она же с сети прошивки получает, а на компе только прошивальщик?
Теперь о твоей флешке. Её никто и никогда не восстанавливал в двухканальный режим? В одноканальный режим её кто может восстановить? У тебя VID/PID меняется при переходе в тест-режим? А что выдаёт OnLineRecovery, когда ты ей флешку в тест-режиме,  то же что и обычно? Может из-за «грубого» замыкания ног, FID читается коряво (как у меня было) и сразу же отправляется на transcend.com (или куда там?), там смотрят что он «левый», но флешка «своя» и дают дефолтную прошивку, или он совпадает с какой-нибудь одноканалкой.
Хотя, скорее всего Alcor залил тебе одноканальную прошивку и теперь у второй flash-памяти не спрашивают FID, я так думаю опрашивается оба FID (хотя надо быть редким извращенцем чтоб поставить разную память), как-то же определяется двухканальное железо при первой прошивке на заводе, когда в контроллере вообще ничего нет.
Попробуй перевести в тест-режим резистором и форматировать OnLineRecovery, да и всем надо попробовать. Просто я не вижу причин по которым Transcend не даёт прошивку для двухканального режима? Она то-у них есть, флешки ж их. Да и Alcor`y какой смысл зажимать прошивку, как она может повлиять на продажи? Ну а если не поможет, то только подменой/переименованием bin-файлов, брать то что программирует твой AN и подсовывать ему двухканальные прошивки под видом одноканальных, вы же разобрались с системой именования файлов?
А, ещё чуть не забыл, у тебя есть datasheet на K9MDG08U5 типа как на твою  Micron MT29F128G08C интересно посмотреть. Типа такого же и на контроллеры должны быть, но наверное их уже удалили за ненадобностью. Вообще мудакам, которые это под NDA засовывают, надо гвоздь в башку забить, нахрена это делать?
Блин 2 метра на вложение в 21-то веке, ну вы звери, и это на форуме по поднятию гигабайтных флех  Короче вы ССЗБ, блин 7zip сжал до 2138кБ при разрешенных 2128, да так даже в Освенциме не жгли собирайте теперь архив по кусочкам, вместо созерцания православного pdf

[nat27]

Ну вот и чудненько, просто спокойно опиши метод восстановления флешек на контроллере алькор известным и понятным тебе методом. В том вся и прелесть авторской методики, что то что не видно одному, другому как на ладони. Люди заходят сюда чтобы восстановить флешку и не их вина что в этом деле они не обучены, очень хорошо что есть утилиты и какие либо инструкции как сделать требуемое дело особо не напрягаясь. Как вести себя на форуме это их право и выбор за который они потом несут ответственность. Уход в личку я предлагал чтобы не засорять тему разными догадками и рабочими моментами, прочитав которые, некоторые могут поступить неправильно опираясь на непроверенные данные этой темы.

Теперь по моей флешке. По какой то причине не удается восстановить флешки у которых контроллер 98 серии с кодом контроллера 0хЕ302(и старше) AU6998AN в связке с памятью L74A (25nm Micron\Intel MLC) в двухканальном подключении. Если взять AlcorMP с зашифрованным флешлистом FlashList.afl в котором присутствует подходящая прошивка 10_85_L74DDP.BIN  то при попытке запуска всегда выходит ошибка 30700: Bad Block:0/8192(B). Такая ошибка бывает при попытке прошить флешку отсутствующей(неподходящей) прошивкой или еще фиг знает по какой причине. Но вот что примечательно, у китайцев выложена интересная утилита оценщик состояния модулей памяти DieSortTool_v12.09.29.00. С помощью этой утилиты прошить флешку нельзя, отсутствуют прошивки контроллер+память, а понять состояние памяти, оценить количество бэд блоков и тип оптимизации при котором удается получить выход наибольшего объема годных ячеек можно. Видимо, получая партию отбраковки, сначала этой утилитой выясняют в каком режиме оптимизации можно выжать из памяти наибольший объем и затем подставляют эти значения в нормальный AlcorMP и шьют партию "подарочных" флешек. Так весь фокус в том что DieSortTool_v12.09.29.00 великолепно работает с AU6998AN в связке с памятью L74A (25nm Micron\Intel MLC) в двухканальном подключении. При операциях оценки состояния памяти в DieSortTool_v12.09.29.00 используются прошивки 10_LB_SCAN.BIN и 10_LB_SORT.BIN объемом 30462кб. В AlcorMP сканирование и сортировка памяти проходят на первом этапе обработки флешки, при этом используются 10_LB_SCAN.BIN и 10_LB_SORT.BIN объемом 26110кб, а только затем идет использование основной прошивки 10_85_L74DDP.BIN. Если говорить точнее, то до основной прошивки 10_85_L74DDP.BIN дело не доходит, появляется сообщение scan и сразу ошибка 30700: Bad Block:0/8192(B), что по моим предположениям является неподходящей прошивкой 10_LB_SCAN.BIN объемом 26110кб. Символ (B) в сообщении ошибки указывает на то что она появилась при попытке сканирования в режиме BlockMode. Утилиты OnlineRecovery от трансценда построены на алькоре с нешифрованным флешлистом  FlashList.ini и скомпонованы они по другому нежели AlcorMP с шифрованным  флешлистом. Упорол я флешку при попытке создания CD-раздела объемом более 4ГБ с помощью AlcorMP_12.12.26. До этого CD-раздел нормально создавал Onlinerecovery_620. А после того как была применена AlcorMP_12.12.26, сервис Onlinerecovery\620\V15 выдает ошибку при восстановлении флешки. Если поставить явно в AlcorMP один канал то флешка восстанавливается с потерей половины памяти, при этом скорость записи на такую половинчатую флешку очень мала, не более 5Мб\с, т.е. полная хрень. У нормальной одноканальной флешки с MLC памятью скорость записи больше 12Мб\с.

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

[Bовка]

Предлагаю попробовать два варианта:
1) Перевести флешку в тест-режим резистором (ногу ты знаешь?), чтоб точно не было искажений на шине. И пробовать сначала OnLineRecovery (тот который в конце коммента), потом AlcorMP прошить.

2) Подменить одноканальную прошивку (имя файла знаешь?) файлом 10_85_L74DDP.BIN скопировав и переименовав его именем одноканалки. Пробовать шить Alcor'ом, выставив один канал, как ты делал, надеясь что прошивка выбирается по имени файла и не проверяется её содержимое. Ну и тест-режим через резистор лишним не будет.

Предполагаю прошивки можно тягать из шифрованной программы в нешифрованную и обратно, так как они совпадают по формату.
Я ковырял OnLineRecovery, который в xls для Transcend 620 указан,  увидел только образ и исполняемый файл ~1,5МБ в котором наверняка нет прошивок и он их из сети тянет. Или я что-то не то ковырял, и этой фигнёй не прошивают?
Чуть не забыл, думаю шить можно что угодно, вернуться в текущее состояние сможешь.

[Anatolij]

nat27
Не пробовали подменять файлы 10_LB_SCAN.BIN и 10_LB_SORT.BIN ?

[nat27]

Одноканальную прошивку SDP менял на DDP не помогает, по размеру прошивки 10_85_L74DDP.BIN в AlcorMP и Onlinerecovery разные, но менял конечно и их не помогает. Файлы 10_LB_SCAN.BIN и 10_LB_SORT.BIN первим делом подставлял из DieSortTool_v12.09.29.00 также ошибка. Утилиты AlcorMP с середины 2012г. идут немодифицируемые, бесполезно добавлять в каталоги дополнительные прошивки, заменять файлы, похоже что конечнику, а затем и нам от китайцев достаются скомпилированные по всем параметрам сборки. Такая утилита не реагирует на добавление новых прошивок. Кстати, в последних утилитах AlcorMP_13.07.10.00 и старше, вместо ошибки 30700: Bad Block:0/8192(B) появляется сообщение 30700: No Support Dual Channle при L74, см.сообщение по гиперссыле, подтверждаю это со своей флешкой. Наконец то это внесли в список ошибок, а то просто приходилось гадать почему нет восстановления на DUAL L74A. А трансценду разрешили восстанавливть DUAL L74A в Onlinerecovery. Похоже что у алькоровцев есть утилита - продолжение нешифрованной серии 1.0.0.14, на основе которой трансценд готовит весьма порезанную Onlinerecovery, впихивая туда адреса своих серверов на которых лежат прошивки. А китайским товарищам алькоровцы передают скомпилированную, с шифрованным flasshlist.afl AlcorMP под конкретные типы флешпамяти. Поковырявшись в exe-шниках onlinerecovery из полезного я увидел новую цифру версии, адреса службы восстановления и ошметки закрытых меню диалогов наподобие тех что мы видим в AlcorMP. Если контролировать каталог TEMP при запуске onlinerecovery, то удается достать нешифрованный flashlist.ini и прошивку для восстанавливаемой в данной сессии флешки, но толку от этого никакого, AlcorMP не воспринимает нешифрованный flashlist.ini и прошивку с онлайнсервиса.

Вовка
Метод 44-ноги могу попробовать, это будет выглядеть так: подключаю на отключенной флешке резистор 5,1к от +5в к 44-ноге, вставляю флешку, через 1-2сек снимаю подключение резистора. Теперь запускаю onlinerecovery и провожу восстановление. Я ничего не попутал? Было бы правильно, если бы ты сам описал эту процедуру во всех мелочах. Представь ситуацию что человек немного знакомый с паяльником решил восстановить флешку по предлагаемому тобой методу и ему нужно детально описать порядок действий.

AlcorMP я всегда успею применить чтобы получить половину тугодумающей флешки, меня интересует возможность полноценного восстановления флешки к фабричному состоянию(с помощью правильно работающего сервиса от трансценда, например).

[Bовка]

 О, хорошо что расписал, чтоб я не предлагал, то что уже опробовано и представлял на что программы капризничают. Теперь предполагаю, что Alcor отдал прошивку на L74 "эксклюзивно" Transcend'y чтоб китайцы не могли прошить и не подделывали это железо. Но неужели двухканалку на L74 только Transcend делает (я не могу пока глянуть xls)? Значит AlcorMP нам не поможет.
Кстати я понял что вы под шифрованной программой имеете в виду только её флешлист. Но почему они не жрут свои прошивки? Но об этом позже.
Про перевод в тест-режим ты всё правильно понял, я только принцип описывал, полагая что реализацию ты и сам сможешь (не прибедняйся ), но таки да подробности не помешают, ты только тоже в подробностях описывай какие ошибки вылетают. Разница в том что вы считаете что тест-режим включается при обнаружении конфликта на шине и замыкаете её, а я считаю что режим включается при + на ноге при включении, а закоротка вредна и только искажает информацию на шине.
Подавай + (с разьёма например) через резистор на нужную ногу (у меня была 44, у тебя какая? В блогах пишут DATA 7, если что найди перебором). Я определял активный тест-режим по появлению Generic Disk и изменению vid/pid USB-устройства в диспетчере устройств  и тогда снимал резистор, проверить что все идентификаторы правильные (я смотрел FID Alcor'ами, так как замыкал ноги циркулем и он часто был неверный). И запускать/форматировать OnLineRecovery. Это всё делать не передёргивая флешку в разьёме.
А вообще известны случаи восстановления двух каналов на L74 ?
А чего ты нормальные datasheet'ы на память не выложил у себя, они конечно мало кому нужны, но всё же?

[nat27]

Даташиты на память гдето по темам выкладывал, кому надо, находят гуглем в пять секунд, это "непрофильные активы", если человеку нужен даташит, то это специалист, а он просто обязан уметь пользоваться поиском. Случаи восстановления флешек трансценд в двухканальной конфигурации L74A бывают почти всегда утилитой onlinerecovery в простых случаях падения флешки за редким исключением.

В моем случае было создание CD-раздела объемом более 4ГБ с помощью AlcorMP_12.12.26, при этом утилита более часа мурыжила флешку, мне надоело ждать, поняв что чтото пошло не так я отключил наживую флешку и наступил крандец. До этого более полугода часто(два-три раза в неделю) заливал на неё проекты AlcorLive объемом 260Mb с созданием CD-области утилитой Onlinerecovery_620, все проходило как по маслу и я расслабился и не сразу сообразил что не надо шутить с флешками с таким оборудованием. Память 25nm Micron\Intel очень ходовая была для SSD дисков многих брендовых производителей, таких как Интел. В двухканальной конфигурации L74A(MLC) попадалась мне только у флешек трансценда, видимо этот эксклюзив больше никому не дали делать или все пластины шли под SSD.
В трансценде при производстве, скорее всего шьют другими, нежели onlinerecovery утилитами. Можно только порадоваться что есть такой сервис, хоть он и корявенький порой. Например, утилита onlinerec_2.0.0.58, похоже сдулась, походу в ее теле идут ссылки на упавший или удаленный сервер технической поддержки, т.к. попытки многих(и мной в том числе) запуска этой утилиты, уже более полугода заканчиваются сообщением о недоступности сервиса трансценда. А стоит запустить новую версию onlinerec_7.0.0.1 как она начинает отвечать. Так что если прошивка 'глубоко' упорота, то онлайнсервису не по зубам, но заводских утилит трансценд не дают, а в жестко скомпилированных AlcorMP DUAL L74A не поддержан.
По сути утилита AlcorMP_1.0.0.14 оказалась случайно не закрытой версией с сервиса восстановления TeamRecovery, там было маленькое оконце с одной кнопкой старт. Всю красоту удалось вытащить нестандартными средствами, к тому же в утилите был незашифрованный флешлист, который можно было править и утилита подхватывала эти исправления, а также добавление новых прошивок позволяло существенно расширить функционал, на радость нам. Сейчас по другому.   
     

[Bовка]

 Понятно, просто я увидел что у тебя продукт-каталог лежит под видом даташитов и подумал что от него толку вообще 0, ну это я уже вредничаю видимо.
По Transcend'y хорошо что обьяснил, то что на производстве их программируют не onlinerec это понятно, но подобной и она как-то видит двухканальное железо, хотя в данном случае может alcor поставляет им preprogrammed контроллеры (всетаки USB-программирование это долго для крупного производства)
Тут плохо что если прошивка только у Transcend и для Transcend и они её жмотят, то хрен они её кому onlinerec'ом выдают (а то сопрут), а восстанавливают флешку сканированием,  сортировкой и т.д. но без прошивки контроллера. Или она шифрованная в Temp падает и прошивка обновляется, это было б хорошо. А в alcormp положили какую-нибудь "заглушку" вместо двухканалки.
Короче рано переживать, пробуй, а там посмотрим.

[nat27]

Добрался до паяльника, припаял 5.1к между FMDATL7 (37нога) и +5в, подключил флешку, после помаргивания через 4-5 сек убрал перемычку. Запустил Onlinerecovery_7.0.0.11, утилита отработала как обычно, в конце сообщение Format Failed 0x1901. Ситуация принципиально не поменялась. Вынул флешку отпаял сопли, запустил AlcorMP(131028.MD), самую свежую из последних, в авто-установках появляется сообщение о невозможности работы в двухканальном режиме. При одном канале, восстанавливается к половине объема, см.скрин.

Вывод у меня такой, проброс +5в через ограничительный резистор на FMDATL7 (37нога), подключение флешки в порт USB и снятие перемычки спустя 4-5 сек это, по сути, другой способ сброса контроллера и перевода его в режим препрограммирования. Похоже что замыкание контактов на шине данных, это аналогичное действие, за исключением тяжелого воздействия на контроллер, когда на соседних замыкаемых ногах образуется закоротка с сильным разогревом контроллера.

Остальные действия по подъему неработоспособной флешки зависят исключительно от подходящей низкоуровневой утилиты и нормальной среды запуска(отсутствие блокировок выполнения утилиты со стороны операционной системы).