Непростой Macronix. Расширяем перечень микросхем, подвластных UNO-программатору

На рын­ке дос­тупно мно­жес­тво мик­росхем памяти SPI Flash 25-й серии, которые сов­мести­мы меж­ду собой по прин­ципу работы и элек­три­чес­ким парамет­рам. Но, как ока­залось, не все они оди­нако­во хорошо работа­ют с са­модель­ным прог­рамма­тором, соб­ранным на осно­ве кло­на Arduino UNO.

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

Еще мы выпол­ним ими­тацию их работы в прог­рамме Quite Universal Circuit Simulator и в кон­це кон­цов най­дем и устра­ним «сла­бое зве­но». Ты уви­дишь, что дли­на соеди­нитель­ных про­водов име­ет зна­чение, но отнюдь не реша­ющее.

От полного непонимания к началу диалога

В пре­дыду­щей статье «UNO-прог­рамма­тор для SPI Flash. Про­шива­ем мар­шру­тиза­тор под­ручны­ми средс­тва­ми» я рас­ска­зал о том, как соб­рал прог­рамма­тор, записав скетч frser-duino в клон Arduino UNO, и успешно при­менил его для записи дам­па про­шив­ки мар­шру­тиза­тора в мик­росхе­му Winbond 25Q128FVSG с помощью ути­литы flashrom. К сожале­нию, мар­шру­тиза­тор с новой про­шив­кой не завел­ся, и воз­никла мысль записать про­шив­ку в мик­росхе­му Macronix MX25L6406E, объ­ем памяти которой в точ­ности соот­ветс­тво­вал раз­меру фай­ла с дам­пом. В спе­цифи­кации на этот чип ука­зано, что он работа­ет на нап­ряжени­ях от 2,7 до 3,6 В и все восемь его кон­тактов име­ют те же наз­начения, что и у пре­дыду­щего «паци­ента».

Я не испы­тывал тре­воги: ну что тут может пой­ти не так? Раз­ве что емкость мик­росхе­мы сос­тавля­ет не 16 Мбайт, а толь­ко 8 Мбайт, но это и к луч­шему — про­цесс зай­мет мень­ше вре­мени. О, как же я оши­бал­ся!

Мне так пон­равилось поль­зовать­ся «кар­трид­жем», изго­тов­ленным из мик­росхе­мы SPI Flash, что изде­лие MX25L6406E я тоже помес­тил на переход­нике SOP8 — DIP8 с кон­такта­ми и уста­новил на панель­ку DIP8 пла­ты прог­рамма­тора с резис­тивны­ми делите­лями для сог­ласова­ния уров­ней сиг­налов. Конс­трук­цию пла­ты тебе напом­нит этот рисунок.

Не ожи­дая никако­го под­воха, я наб­рал коман­ду, что­бы узнать иден­тифика­тор мик­росхе­мы в кон­тек­сте UNO-прог­рамма­тора:

Но вмес­то ожи­даемых све­дений на экра­не появи­лось сооб­щение об ошиб­ке:

Что такое? Прог­рамма­тор не видит мик­росхе­му? Навер­ное, кон­такты окис­лились. Отклю­чил прог­рамма­тор, дос­тал кар­тридж, про­тер его нож­ки, уста­новил обратно, пов­торил коман­ду. Опять не видит! Про­верил соеди­нитель­ные про­вода и не обна­ружил оши­бок ком­мутации. Но прог­рамма­тор про­дол­жал упорс­тво­вать: никакой мик­росхе­мы не под­клю­чено. И спо­рить с ним было бес­полез­но.

Я перечи­тал спе­цифи­кацию MX25L6406E и не нашел ничего нового для себя. Резуль­таты поис­ка в интерне­те тоже не дали готово­го решения. Те, у кого воз­никла такая же проб­лема, в основном сетова­ли на боль­шое количес­тво под­дель­ных чипов и отка­зыва­лись от даль­нейших попыток. Но встре­тилось нес­коль­ко упо­мина­ний о том, что иног­да прог­рамми­рова­ние про­ходит с боль­шей ста­биль­ностью при понижен­ном нап­ряжении. Это уже кое‑что!

Нем­ного понизить нап­ряжение питания про­ще все­го пос­ледова­тель­ным вклю­чени­ем на линии VCC диода в пря­мом нап­равле­нии. Я под­клю­чил диод 1N4148, и нап­ряжение с 3,3 В упа­ло до 2,9 В. При этом оно все еще находит­ся в допус­тимом диапа­зоне, который ука­зан в спе­цифи­кации.

В ответ на пов­торный ввод коман­ды я уви­дел такие стро­ки:

Ну вот, дело сдви­нулось с мер­твой точ­ки! Про­читан­ному прог­рамма­тором иден­тифика­тору мик­росхе­мы удов­летво­ряют нес­коль­ко моделей чипов, и нам пред­лага­ется ука­зать кон­крет­ный модель­ный ряд с помощью парамет­ра -c. В нашем слу­чае под­ходит вто­рой из пред­ложен­ных вари­антов, поэто­му коман­ду записи фай­ла zte_h118n.bin, раз­мер которо­го сов­пада­ет с емкостью мик­росхе­мы, мож­но сфор­мулиро­вать так:

На экра­не побежа­ли информа­цион­ные сооб­щения выпол­няемо­го про­цес­са, но завер­шился он неуда­чей:

Вот так, при свер­ке было обна­руже­но 88 659 рас­хожде­ний, а мик­росхе­ма переш­ла в неоп­ределен­ное сос­тояние.

Как слышно? Прием!

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

Мо­жет быть, понизить нап­ряжение не питания, а информа­цион­ных сиг­налов? Давай поп­робу­ем! Тем более что для это­го нам не при­дет­ся вно­сить сущес­твен­ных изме­нений в конс­трук­цию. У нас уже есть три «понизи­теля» нап­ряжения на резис­тивных делите­лях. Для ясности схе­му одно­го из них я показал на рисун­ке.

Ес­ли уве­личи­вать соп­ротив­ление резис­тора R1, то нап­ряжение сиг­нала на выходе будет умень­шать­ся. А для уве­личе­ния соп­ротив­ления дос­таточ­но пос­ледова­тель­но к R1 под­клю­чить резис­тор R3. Это мож­но сде­лать даже без пай­ки, прос­то скру­тив один вывод резис­тора R3 c кон­цом соеди­нитель­ного про­вода, а дру­гой вывод исполь­зовать в качес­тве ште­кера.

Что­бы сни­зить риск пов­режде­ния мик­росхе­мы памяти во вре­мя экспе­римен­тов, я решил сна­чала добить­ся устой­чивого чте­ния, а к записи перей­ти поз­же. И вот, убрав диод с линии питания и под­клю­чив на линии SCK (вывод 13 UNO-прог­рамма­тора) и MOSI (вывод 11 UNO-прог­рамма­тора) по одно­му добавоч­ному резис­тору соп­ротив­лени­ем 2000 Ом, я выпол­нил чте­ние содер­жимого мик­росхе­мы памяти.

Но как узнать, было ли это чте­ние безоши­боч­ным, если дан­ные в мик­росхе­му были записа­ны с ошиб­кой? Срав­нение с исходным фай­лом в этом слу­чае ничего не даст. Тог­да я решил выпол­нить чте­ние еще раз и срав­нить меж­ду собой получен­ные резуль­таты. Если они сов­падут, то цель дос­тигну­та. А если нет, то за оцен­ку количес­тва оши­бок чте­ния мож­но при­нять величи­ну d/2, где количес­тво рас­хожде­ний d зна­читель­но мень­ше раз­мера фай­ла (пос­мотри на рисунок).

У меня получи­лось d = 399 858 рас­хожде­ний, что соот­ветс­тву­ет 199 929 ошиб­кам, или ошиб­кам в (199 929 / 8 388 608) × 100 = 2,38% байт. Нас­коль­ко мож­но доверять такой оцен­ке и нас­коль­ко она ста­биль­на? Может быть, в сле­дующий раз будет 25%, а потом 0,01%?

Обратимся к статистике

Что­бы не гадать на кофей­ной гуще, я решил при­бег­нуть к ста­тис­тике. Для это­го написал на Python прог­рамму compare.py, которая побай­тово срав­нива­ет два фай­ла и под­счи­тыва­ет количес­тво обна­ружен­ных раз­личий.

Вот лис­тинг прог­раммы compare.py для побай­тового срав­нения двух фай­лов.