W
ciągu ostatnich miesięcy pojawił się problem reanimacji Kenwoodów po nieudanym
patchowaniu, albo po nieudanych próbach modyfikacji zawartości flashy przy
pomocy jtaga. Sam doświadczyłem problemu, nieudolnie postępując z Dtf1. Liczne
dyskusje w sieci i pojawiający się na uploadach plik o zmiennej nazwie "Ratunek
dla xxx" przekonały mnie, że jedyny sposób na postawienie Kena na nogi to
wykorzystanie prg3a4_2.dat.
Ostrzeżenia
Jeśli dekoder nie jest waszą własnością nie powinniście w nim grzebać i go
rozkręcać.
UWAGA!!! ABY NIE UWALIĆ TUNERA NAJPIERW PRZECZYTAJ CAŁY TEKST A POTEM DZIAŁAJ, NIEKTÓRZY ROBIĆ NA ODWRÓT ALBO JEDNOCZEŚNIE CZYTAJĄ I DOKONUJĄ PRZERÓBEK, POTEM PŁACZĄ!
Najbardziej interesujące rozważania prowadzone były na forum belsattv w marcu i kwietniu br. Temat rozważań "Ubił Kenwood ..." mowi sam za siebie. Moim skromnym zdaniem wokół sprawy narosło zbyt wiele mitów a zbyt mało jest pracy u podstaw. Osobom zorientowanym w temacie pewnie niewiele nowego lektura tego tekstu przyniesie, ale może warto uporządkować wiadomości dotyczące adresowania flashy w Dtf1 i Dtf2. Wiedza o sposobie komunikowania się procesora z flashami na pewno pozwoli na napisanie skutecznego programu reanimacyjnego dla Kenwoodów. Ze swoim Dtf1 poradziłem sobie sam, ale dla wielu problem istnieje.
Procesory zbudowane na bazie ST20 da adresowania wykorzystują 32 bitową szynę
danych. Flashe w różnego typu dekoderach można najczęściej znaleść pod adresami
50000000, 60000000 i 7fe00000. Pytanie natury zasadniczej: Czy bit A0 magistrali
adresowej procesora pokrywa się z bitem A0 pamięci flash pracującej w trybie
word lub bitem A-1 pamięci flash pracującej w trybie byte?. Otóż nie. I w tym
cały problem. W Dtf1 flash 512kx8 bit A-1 pokrywa się z bitem A0 szyny adresowej
procesora. Toteż z algorytmem procedury zapisu flasza nie trzeba kombinować.
Podobnie jest z małym flashem w DTF2. Trochę inaczej jest z flashem 2Mx8 w Dtf1.
Ten flash ma swój bit A0 podłączony do bitu A1 szyny adresowej procesora. Stąd
zmiana adresu instrukcji pod które trzeba przesłać dane we wstępnej fazie zapisu
danych da flasha. Przy pisaniu trapa do zapisu tego flasha adres xxxx5555 trzeba
zmienić na xxxxAAAA. Ponieważ flash nie "widzi" LSB szyny adresowej procesora,
na swej szynie adresowej widzi 5555, czyli to co powinno się tam pojawić.
Podobnie adres xxxx2AAA trzeba zmienić na xxxx5554. Analogicznie na swej szynie
adresowej flash widzi 2AAA. Z tych właśnie powodów oryginalny Prg3a4_2.dat
błędnie pracuje w dekoderach, które mają bit A0 flasha podpięty do bitu A1 szyny
adresowej procesora. W Dtf2 są dwa flashe 1Mx8 podpięte pod ten sam adres,
ustawione są na sztywno do pracy w trybie word i rzecz najważniejsza linie
danych flashy są podpięte do dwóch różnych połówek magistali danych procesora.
Bit A0 obu flashy jest podłączony do bitu A2 linii adresowej procesora. Znane mi
trapy do zapisu flashy tego faktu nie uwzględniają. Jeżeli w jakiś sposób uda
się cokolwiek zapisać do flashy pracujących w tej konfiguracji to będzie to
przekładaniec dwa normalne bajty dwa puste. Oba flashe muszą być zapisywane
równocześnie i by tego dokonać, do budowy trapa trzeba wykorzystać instrukcje
procesora devsw a nie devss. Standartowa procedura zapisu flasha dla trybu word
to: pod adres 5555 przesłać AA, pod adres 2AAA przesłać 55, pod adres 5555
przesłać A0 i ustawić adres pod który przesyłamy dane. By spełnić wymagania tej
procedury procesor musi podczas zapisu wystawić adres xxx15554 zamiast xxxx5555
oraz adres xxxxAAA8 zamiast 2AAA. Ponadto by oba flashe ustawić w tryb zapisu
dane trzeba zdublować. Procesor na linii danych musi wystawić AA00AA zamiast AA,
550055 zamiast 55 i A000A0 zamiast A0. By reanimacja Dtf2 była udana program
prg3a4_2.dat musi być zmodyfikowany przy uwzględnieniu tych faktów.
Jak wynika z tych rozważań by prawidłowo zaprogramować flashe w Kenwoodach,
wystarczy znać konfigurację w jakiej te flashe pracują. Jeżeli najmniej znaczący
bit linii adresowej flasha jest podłączony do linii A0 magistrali adresowej
procesora to trap powinien wykorzystywać instrukcje procesora devsb device store
byte. Jeżeli A0 flasha jest podpięte do linii A1 procesora to trzeba
wykorzystywać instrukcję devss device store sixteen. Gdy A0 flasha jest
podłączone do A2 procesora to musi być stosowana instrukcja devsw device store
word.
Co może się dziać dziwnego w Kenwoodzie pozbawionym oprogramowania. Odpowiedż
jest prosta. Nic.
ps. Funkcja sector protect obejmuje swym działaniem zarówno zapis jak i
kasowanie flasha. Jeżeli flasha daje się kasować to tym samym nie stosuje się
tej funkcji w Kenwoodach. Podłączanie nogi reset flasha do 12V usuwa czasowo
blokadę sector protect ale z praktycznego punktu widzenia nie ma to znaczenia
przy reanimacji Kenwoodów.
