Катюша M133P - Поговорим!

[mihas000]

Парни всем приветы

Есть вопросик
В общем имеем два дампа вычитанные разными прогерами, так вот они отличаются конкретно
Гляньте кто шарит в чем прикол
downloads/?b=731
downloads/?b=726

[kgbeast]

Internal ECC надо отключать, твой дамп W25N01GVZEIG_настройки.bin считан с включённым внутренним ECC, а 25N01GVZEIG.bin с какими настройками был считан?

[mihas000]

Если который UFPI там нет настроек, он полностью вычитывает с бэдами и со спаре
Я не пойму почему такие отличия в дампе, не прогер ли косячит

Вот лог от UFPI

log.txt

(6.59 КБ) 10 скачиваний

[kgbeast]

Ну если верить логу то, Configuration Register 0x08 (BUF) означает, что UFPI выключил внутренний ECC
0 0 0 0 1 х х х
бит7 - ОТП лок (0 - не залочена)
бит6 - ОТП энтер (0 - не в режиме чтения ОТП)
бит5 - SR1 lock (0 - не залочен)
бит4 - ECC-Enable (0 - выключен)
бит3 - Буфер (1 - использовать)
бит2-0 - зарезервированы

Т.е. твои дампы считаны с разными настройками Internal ECC

Отправлено спустя 20 минут 48 секунд:
Ещё странность.
В логе есть сведения что прогер вычитал внутреннюю таблицу подстановки бэдблоков
нулевой блок в спэр-области (байт по адресу 0х800) имеет маркер бэдблока (значение отличное от FF)
В логе сказано что блок0 должен быть замещён блоком3FFF, но у этой нанд всего 1024 блока, т.е. в LUT есть запись что блок0 - бэдблок, но нет записи какой блок его замещает. И остальные 8 блоков указывают на тот же блок 3FFF.

Отправлено спустя 10 минут :
По ощущениям дамп W25N01GVZEIG_настройки.bin полностью запорот. Дамп считанный UFPI выглядит более логичным, что-ли...

[mihas000]

Файл W25N01GVZEIG_настройки.bin считан chipprog, с рекомендованными настройками от официалов, выглядят они так: отключаем обнаружение БЭД, включаем спаре, и выставляем максимальное число байт для этой микры. как бы все логично

[kgbeast]

Ну смотри
начало дампа 25N01GVZEIG.bin и следующей стройкой начало дампа W25N01GVZEIG_настройки.bin

Код: Выделить всё

1B 2A 6D 00 D0 00 00 0B 21 C3 C8 00 F8 04 03 00 40 00 10 06 00 00 00 00 18 F0 9F E5 18 F0 9F E5
1B 2A 60 00 00 00 0C 32 10 0C 80 48 00 03 00 40 06 10 00 00 00 00 01 8E 59 FF 01 8E 59 FF 01 8E

Видно что в дампе уже вначале "съеден" байт 0xD0 и чем дальше, тем больше таких "скушенных" чиппрогом байтов. Обрати внимание на сколько съехала область spare. В дампе от чиппрога она начинается с байта 0x7BC. То есть прог потерял 68(!) байт. Поскольку чтение идёт страницами, то каждые 2112 байт всё повторяется. Можно заморочиться и попробовать подобрать параметры ECC, чтобы проверить насколько корректные данные считал UFPI, но дамп от чиппрог только в мусорку.

[mihas000]

я вот и не вкурю, толи чипрог не корректно понимает это микруху

[kgbeast]

толи чипрог не корректно понимает это микруху

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