Programator Pamięci BIOS Flash SPI v2.0

Teehlek napisał(a):Firstly, I already finished the programmer refer from Sebastian website.

We only support the programmer based on our hardware project (2.0 version).

Vogelek23 napisał(a):

Teehlek napisał(a):Firstly, I already finished the programmer refer from Sebastian website.

We only support the programmer based on our hardware project (2.0 version).

Thanks for reply.
Could you kindly help to check whether this 2.0 version can program *.bin file without any problem ?
Due to SPI flash programmer didn't mention about compatible file type, so I don't know this program is just blind write.
(I mean the program not care what's extension file, it will keep write data to the chip ?)

In case I have to make 2.0 version, can I use through-hole components instead of SMD ?
What's the reason behind why you choose SMD device ? Is it stable than old-fashion parts ?
It's quite a bit difficult to find all component in SMD type here. (--"

Sorry that I have so many questions. I'm a newbie in chip programmer.
Hopefully I will heard your reply soon.
I'm also appreciate other GURUs to clarify me.

Thank you

Teehlek napisał(a):Could you kindly help to check whether this 2.0 version can program *.bin file without any problem ?

1. The file you've linked is *.rom file.
2. Software written by Sebastian Bartkowicz supports *.rom file extension - I'm using *.rom files usually.
3. If possible, please assemble the programmer hardware basing on our project (2.0 version).
4. What is your LPT cable length (in cm)? Does it has a ferrite cores near the plugs?

Vogelek23 napisał(a):

Teehlek napisał(a):Could you kindly help to check whether this 2.0 version can program *.bin file without any problem ?

1. The file you've linked is *.rom file.
2. Software written by Sebastian Bartkowicz supports *.rom file extension - I'm using *.rom files usually.
3. If possible, please assemble the programmer hardware basing on our project (2.0 version).
4. How long is your LPT cable (in cm)? Does it has a ferrite rings near the plugs?

Thanks for your prompt reply. I'm not so sure how long is the cable.
It's probably more than 100 cm (1 meter) without ferrite core.
I will try to reduce the cable length and use *.rom first.
If still not work, I will build new hardware as last resort.
BTW, can I use through-hole components ? As I quoted before, SMD components is quite rare in my home town.
Any effect here ?

P.S. I just recognize that many people simply change extension from *.rom to *.bin and use .bin format in ATiflash program.
It's very curious, isn't it ?

Witam serdecznie

Złożyłem w całość programator, jednak mam problem, ponieważ program SPIflash nie wykrywa mi urządzenia. Przy próbie test hardware otrzymuję informację hardware not present i czasami wyrzuci niebieskie ekran z błędem io.sys. Programator podłączony mam przez kabel LPT 25pin oraz zasilanie programatora 12V. Kabel LPT jest OK ponieważ wykorzystuję go do programatora Willem.

misiek853 napisał(a):Przy próbie test hardware otrzymuję informację hardware not present i czasami wyrzuci niebieskie ekran z błędem io.sys.

Dla pewności sprawdź na innym PC, obstawiam jednak błąd w poskładaniu urządzenia.
Posprawdzaj wszystkie punkty lutownicze, może gdzieś masz "zimnego luta", sprawdź czy wszystko masz poprawnie poskładane.

Programator już działa poprawiłem płytkę i jest OK

Właśnie złożyłem programator - był w sklepie tylko układ M74HC24481.

Podobnie jak kolega mam przy próbie test hardware komunikat hardware not present.
Sprawdziłem miernikiem połączenia i wszystkie są ok (łączone na płytce uniwersalnej, Win7 32Bit).

Czy do wykrycia programatora przez SPI Flash jest potrzebny cmos w podstawce dip8?

Czy trzeba coś przestawiać w ustawieniach portu? np. używanie przerwania itp, wykrywanie starszego sprzętu?

Czy zastosowany układ M74HC24481 będzie działał?

Zasilanie roboczo z USB +5V.

Kabel ma długi - około 2m - taki miałem od drukarki - czy to wpływa?

Proszę o pomoc.

Przy próbie zapisu w SPI FLASH wyświetla komunikat "scrollbar property out of range". Odczyt jest poprawny. Co może być przyczyną?

sebastiank napisał(a):Właśnie złożyłem programator - był w sklepie tylko układ M74HC24481.

Kolego, na pewno M74HC24481, czy może jednak M74HC244B1?
Jaki komputer i jaki jest w nim rodzaj portu LPT?
To są istotne - jak dla mnie - informacje.

sebastiank napisał(a):Sprawdziłem miernikiem połączenia i wszystkie są ok (łączone na płytce uniwersalnej, Win7 32Bit).

Zwracam uwagę, iż zaprezentowany tu schemat programatora różni się nieco (m. in. wartości rezystorów szeregowych w szynach; R1, R2, oraz od R4 do R7) od schematu zaprezentowanego przez pierwotnego autora tego programatora, a opisanego tam: http://spiflash.org/block/4.html
Należy też zauważyć, iż odnośnie tego co napisano tam jak niżej:

Warning! SO data line need pull-up resistor (not placed on schematics), SO data line splits into two nets so please use wire to jumper it (pin 7 of JTAG connector with pin 2 of DIP8 socket)
For improoved compatibility with MX and SST device fafmilies do the following modification:
Cut the trace leading to pin #20 of 74hct244 chip, reconnect it using jumper wire with pin #8 of 25xx DIP8 socket

to w schemacie przedstawionym tu zostało to zrealizowane - rezystor R3 (pull-up) jest oraz poprawnie zaprojektowano przedstawione tu PCB.
Ale zalecane tam połączenie -> (pin 7 of JTAG connector with pin 2 of DIP8 socket) jest tam błędnie opisane, dotyczy to pin-3 złącza JTAG (tu nieużywanego i niewidocznego na schemacie).
Mam też wątpliwości co do celowości zastosowania w przedstawionym tu schemacie dławika PL2 - IMHO, należy go zewrzeć.
Zamieniłbym też miejscami kondensatory PC1 (100nF) z PC3 (10µF).

sebastiank napisał(a):Czy do wykrycia programatora przez SPI Flash jest potrzebny cmos w podstawce dip8?

Dla wykrycia podłączenia samego programatora nie jest potrzebny (program wykorzystuje tu sprawdzenie przejścia sygnału z pin-9 złącza DB-25 poprzez wejście-wyjście nr 4 bufora (z pin-4 do pin-12), do pin-12 złącza DB-25), ale - oczywiście - programowany/odczytywany układ ma być włożony w podstawkę dla przypadku użycia przycisku ID (Read ID), ponieważ bez niego to program obsługujący ten programator nie ma swego "adwersarza", więc z kim ma "dyskutować"?

sebastiank napisał(a):Czy trzeba coś przestawiać w ustawieniach portu? np. używanie przerwania itp, wykrywanie starszego sprzętu?
Czy zastosowany układ M74HC24481 będzie działał?

Patrz wyżej oraz niżej ...

sebastiank napisał(a):Zasilanie roboczo z USB +5V.

Nic mi nie wiadomo o typie użytego układu do odczytania/zaprogramowania, a istotne jest by układy niskowoltowe (3,3V) nie były zasilane napięciem wyższym (5,0V) - jak również i sam układ bufora 74HC244.

sebastiank napisał(a):Kabel ma długi - około 2m - taki miałem od drukarki - czy to wpływa?

Kabel a 'kabel' - ja widziałem takie różne i niekiedy całkiem dziwne zachowanie się urządzeń spiętych takim 'kablem'.
Nie ulega kwestii, iż im krótszy kabel tym lepszy, ale też istotny jest - patrz wyżej - rodzaj użytego portu LPT w komputerze.
Ja używam kabla własnej produkcji o długości ok. 80cm a wykonanego z płaskiej 25-przewodowej taśmy (taka jak do FDD, czy do PATA HDD) z zaciśniętymi złączami DB-25 po obu stronach - nawet po jednej stronie dwoma, czyli MALE i FEMALE, a co pozwala mi podłączyć każdy z posiadanych przeze mnie programatorów.
I dotąd - korzystając z stacjonarnego PC-eta oraz wybranego w BIOS portu EPP-ECP - nie miałem żadnych kłopotów z komunikacją pomiędzy komputerem (pod Windows XP-32) a różnymi i używanymi przeze mnie programatorami (oczywiście, programatorami w pełni sprawnymi oraz obsługiwanymi przez właściwe do nich oprogramowanie).

sebastiank napisał(a):Zasilanie roboczo z USB +5V.

Projekt uwzględnia dość ściśle zakres napięć zasilania - od 9V do 20V DC. Ponadto w testach, przy próbie zasilania z USB tego samego komputera, tworzyła się pętla masy, co przekładało się na piękne wzorki na oscyloskopie przy badaniu chociażby linii zasilania.

sebastiank napisał(a):Kabel ma długi - około 2m

Maksimum dla kabla bez "filtrów" przy wtyczkach to około 1,2-1,3m, zaś dla kabla "filtrowanego" około 1,5-1,6m.

GregB napisał(a):Mam też wątpliwości co do celowości zastosowania w przedstawionym tu schemacie dławika PL2 - IMHO, należy go zewrzeć.

Testy prototypu wykazały, że przy zasilaniu z zasilacza niestabilizowanego brak tego dławika (zwarcie) pogarsza nieznacznie "widmo" napięcia zasilania.

GregB napisał(a):Zamieniłbym też miejscami kondensatory PC1 (100nF) z PC3 (10µF).

Może Kolega uzasadnić tę tezę (broń Boże, bym się czepiał, pytam z czystej ciekawości zagadnienia i potrzeby zaspokojenia wciąż "głodnej" wiedzy)?
Ten typ stabilizatora (z diodą "programowalną") niemal w każdej "poważnej" konstrukcji posiada "mniejszy" kondensator na wejściu a "większy" na wyjściu - dlatego tak to rozwiązałem. Faktem jest, że aby to było zrobione do końca właściwie, należałoby umieścić 1x100nF "przed" dławikiem PL1 (od strony gniazda DC), zaś "za" PL1 (od strony stabilizatora) dołożyć 1x10uF oraz 1x1uF. Ja zrezygnowałem z takiego "okładania" pojemnościami, bo w testach poprawa "widma" napięcia zasilania była prawie niezauważalna.

GregB napisał(a):czy może jednak M74HC244B1?

- zgadza się - to układ B1 źle odczytałem.

GregB napisał(a):Jaki komputer i jaki jest w nim rodzaj portu LPT?

- FS Lifebook e8110 - port LPT sprzętowy, w biosie ustawiony na "auto"

GregB napisał(a):iż zaprezentowany tu schemat programatora różni się nieco (m. in. wartości rezystorów szeregowych w szynach; R1, R2, oraz od R4 do R7) od schematu zaprezentowanego przez pierwotnego autora tego programatora, a opisanego tam: http://spiflash.org/block/4.html
Należy też zauważyć, iż odnośnie tego co napisano tam jak niżej

- składałem wg schematu z tego tematu (poza zasilaniem, które podpiąłem z USB) - post pierwszy. Nie wykonywałem dodatkowych czynności.

GregB napisał(a):Nic mi nie wiadomo o typie użytego układu do odczytania/zaprogramowania

- na razie próbowałem bez układu do zaprogramowania, stąd pytanie czy sam programator powinien być wykryty.

Kabel od drukarki - ekranowany, ekran podpięty do masy. Właściwie nie potrzebuję tak długiego - skrócę do kilku/kilkunastu cm.

Vogelek23 napisał(a):Projekt uwzględnia dość ściśle zakres napięć zasilania - od 9V do 20V DC. Ponadto w testach, przy próbie zasilania z USB tego samego komputera, tworzyła się pętla masy, co przekładało się na piękne wzorki na oscyloskopie przy badaniu chociażby linii zasilania.

Masa USB i masa LPT są połączone na płycie głównej - nie pomyślałem o problemach. Zasilanie dopiero zamierzam dobudować. Na razie wyłożyłem się na wykryciu samego programatora (składałem go 2 razy zanim napisałem ), nawet nie włożyłem jeszcze układu do odczytu/programowania.

GregB napisał(a):Nic mi nie wiadomo o typie użytego układu do odczytania/zaprogramowania, a istotne jest by układy niskowoltowe (3,3V) nie były zasilane napięciem wyższym (5,0V) - jak również i sam układ bufora 74HC244.

- w poprzedniej wersji programatora ktoś proponował zasilanie z USB - z jakim skutkiem - nie wiem.

sebastiank napisał(a):w poprzedniej wersji programatora ktoś proponował zasilanie z USB - z jakim skutkiem - nie wiem.

Aby zasilać ten układ z 5V, trzeba wyrzucić obecny stabilizator i założyć LDO (dla kości 3,3V), ponieważ ten stabilizator niezbyt dobrze radzi sobie z napięciem zasilania poniżej 6V (potrafi "pływać"). Dla kostek 5V, przy zasilaniu z USB nie byłby potrzebny żaden stabilizator. Jednakże, jak już wspomniałem, zasilanie z USB tego samego komputera jest nietrafionym pomysłem, z uwagi na w/w pętlę masy i zakłócenia.

GregB napisał(a):istotne jest by układy niskowoltowe (3,3V) nie były zasilane napięciem wyższym (5,0V) - jak również i sam układ bufora 74HC244

Tak naprawdę - w praktyce - nie ma żadnego problemu z zasilaniem kostki oraz bufora napięciem 5V (mówię tu o kostkach "niskowoltowych"). Naprawdę dobrze "odrobiłem tę lekcję" i nawet w przypadku, gdyby przypadkowo założyć zworkę przy wpiętej w DIP8 pamięci "niskowoltowej", nic się nie ma prawa stać ani z pamięcią, ani z buforem (nawet w trakcie programowania czy odczytu pamięci - z uwagi na niskie, względem maksymalnego, taktowanie pamięci, następuje redukcja mocy strat przy przechodzeniu sygnałów ze stanu niskiego do wysokiego i odwrotnie).
Najważniejsze jest, aby nie dopuścić do sytuacji, kiedy pamięć zasilamy napięciem 3V, zaś bufor napięciem 5V (co niniejszy układ realizuje w 100% przez wspólne zasilanie obu układów). Kolega zapewne dobrze zdaje sobie sprawę z tego, co się dzieje z logiką pamięci, która otrzymuje sygnały sterujące o amplitudzie wyższej o 0,6V (lub więcej), niż wynosi napięcie zasilania kostki.

Dorobiłem zasilanie - zasilacz stabilizowany 12V + L7805 + 2 kondensatory. Kabel skrócony do ok. 5 cm (wtyczka przykręcona do płytki). Wszystkie połączenia sprawdzone.
Po podłączeniu nadal komunikat komunikat hardware not present (bez układu do programowania).
Pozostaje już chyba tylko zakup kolejnego M74HC244B1.

Po podłączeniu nadal komunikat komunikat hardware not present (bez układu do programowania).

Dlaczego Kolega "przyczepił się" do tego komunikatu? Po prostu tak już jest, to kwestia softu. Proszę podłączyć dowolną kość SPI i sprawdzić przyciskiem ID (po wybraniu z listy "rodziny" układu), czy kość jest poprawnie identyfikowana.

GregB napisał(a): Dla wykrycia podłączenia samego programatora nie jest potrzebny (program wykorzystuje tu sprawdzenie przejścia sygnału z pin-9 złącza DB-25 poprzez wejście-wyjście nr 4 bufora (z pin-4 do pin-12), do pin-12 złącza DB-25), ale - oczywiście - programowany/odczytywany układ ma być włożony w podstawkę dla przypadku użycia przycisku ID (Read ID), ponieważ bez niego to program obsługujący ten programator nie ma swego "adwersarza", więc z kim ma "dyskutować"?

To odpowiedź na pytanie czy interface powinien być wykrywany - dlatego się przyczepiłem...
Na początku próbowałem z uwaloną kością - stąd pewnie problemy
Ale już się nie czepiam - przylutowałem na próbę sprawny układ i można sprawdzić ID, odczytywać, programować, weryfikacja przechodzi pomyślnie, nie próbowałem jeszcze tylko wstawiać w płytę (układ wyjęty ze złomu, więc efekt byłby i tak nieznany).
Właściwie to chyba wszystko działa pomimo komunikatu hardware not present - w przyszłym tygodniu może będę miał pewność po zaprogramowaniu i wsadzeniu w płytę.

sebastiank napisał(a):zasilacz stabilizowany 12V + L7805 + 2 kondensatory.

Ale po co stabilizator 5V, skoro cały układ jest zasilany napięciem z przedziału 9-20V?
Albo Kolega zbudował zupełnie inny układ niż ten z niniejszego projektu, albo po prostu niepotrzebnie komplikuje sprawę.

Bloku zasilania nie budowałem (brak elementów) - zastosowałem w zamian stabilizator 5V i diody - miałem akurat pod ręką. Zejście do 3V - 3xdioda prostownicza + rezystor wymuszający przepływ prądu. Skoro układ działa będę jeszcze testował zasilanie z USB.

-------------------------------
Testowałem zasilanie z USB (zasilanie podpięte do n.20 74HC255) na układzie SST25VF080B (zasilanie 3-3,6V) - bez problemu się kasuje, programuje i weryfikuje zarówno przy zasilaniu 5V jak i po obniżeniu przez 2 diody do 3,6V (zastosowałem 3 diody szeregowo,można pobierać zasilanie wybranej nóżki, ostatnia dioda połączona do masy przez R 10k dla wymuszenia przepływu prądu przez diody) .

Sprawdzane na laptopie FS 8110 ze sprzętowym LPT.

Otrzymuję komunikat "Unable to start io.sys service. error code = 1275". Potem "IO.DLL not found". Program Terminating. Próbowałem ten plik wrzucić do system32, ale bez rezultatu.

Rozumiem, że to wina 64-bitowego systemu? Jakieś pomysły?

nrasta napisał(a):Otrzymuję komunikat "Unable to start io.sys service. error code = 1275". Potem "IO.DLL not found". Program Terminating. Próbowałem ten plik wrzucić do system32, ale bez rezultatu.

Też miałem ten problem - uruchamiam jako administrator + zgodność z XP - za pierwszym razem ten sam komunikat, zamykam, uruchamiam drugi raz i już nie ma komunikatu i programuje bezproblemowo.