BRAWO!!! :)
tylko, co tak późno montaż. Nie mogę się doczekać efektu.
Printable View
BRAWO!!! :)
tylko, co tak późno montaż. Nie mogę się doczekać efektu.
Bubu, porównywałeś dwa pliki - jeden zapełniony, a drugi mający 0xFF w pewnych miejscach. Chcesz powiedzieć, że ten z 0xFF to ma być "czysty zapis"? Taki jak fabryka dała?
Programator mam i jak Ci się uda pogrzebie też.
Sama czapa na głowie? Bez odlutowania żadnego rezystora na płycie?
Myślałem, że niektóre piny uP są na płycie pull'up'em itd. traktowane by przy bootstrapie nie wchodziło w debug np. pin /IRQ itd.
- zasada jest taka ze /IRQ oraz/RESET odpinamy opory.
- programator na /IRQ podaje + 9V1 wolta, to taki chyba mod boot dla motoroli.
- martwi mnie tylko jedno, z tego mego DTE żaden schemat nie pasuje, dwa razy sprawdzałem a schematów jest w nim 3 sztuki.
- a chciałbym na stole podłaczyć zasilanie i linią K zobaczyć czy nie ma tego 0x001 błedu.
- ponieważ wyczytalem na forum, ze zmiana w eepromie likwiduje bład 0x001 ale ewentualne crashe to tylko rom. ( też to zweryfikuję )
- a w tym programatorze nie mam opcji zapisu do rom-u.
- dlatego uśmiecham się do osoby która posiada DTE i załączy następny schemat z łączówką 36 ( 50 ) pinów.
- ze zrozumiałych wzgledów nie mogę komentować zapytania Marcin_TM, to w końcu poduszki.
Rozumiem.
ładne stronki: KLIK1 KLIK2 KLIK3 KLIK4
Bubu,a nie da się po pinach uP i kondziorkach dojść do zasilania? Wystarczy chyba samo zasilanie i sygnał załączenia zapłonu.
Co do FLASH'a i EEPROM'a tego uP to jest dotęp,ale programowy po przez ustawienie rejestrów FLCR, FLBPR, bez tego nic nie zdziałasz. Programator nie ma możliwości ustawiania bitów tych rejestrów.
Próbowałeś flash'a:
http://gem.win.co.nz/mario/hc08/projects/pgmr.html z
http://zapodaj.net/images/fad1d9ded88d.jpg
Jakiś tam załącznik jeszcze ;-)
- na razie testy sensorów do naprawy na stole po podłączeniu zasilania.
- jak widać czasami FES (fiat ecu scan ) robi błędy.
- żaden inny program nie odczytał tego błędu 0x6B.
- ale wiem jakie mam poduszki typ 2F - 2P - 2L + S, czyli 4 poduszki.
- schemat dla 4 poduszek jest poprawny, dla testów na stole masę łączymy do pina 24, lub 25.
- ten pin 40 to jest masa logiczna a nie masa elektryczna.
- sensor potrafi wykryć brak dobrej masy i dlatego takie cudowanie.
--
http://www.forum.alfaholicy.org/show...&postcount=503
--
Też doszedłem ;-)
Te masy są galwanicznie izolowane? Z ciekawości pytam.
- TAK, nawet sensor wykrył że testowałem go bez obudowy.
- ale bład 0x001 zniknał, wszytkie liczniki wyzerowane.
- interesuje mnie jeszcze pokutujące określenie że bład 0x001 spowodowany jest akumulatorem dośc słabym aby zasilić sensor.
- zasilanie obnizyłem do 7.5 v.
- tylko program KWP71 mógł odczytac sensor, ale odczytał i nie spowodowało to blędu 0x001.
- jednak wyglada na to , że ten licznik (bład ostateczny ) włacza sie wtędy jeśli ilość nie skorygowanych błędów przekroczy ustalony licznik, chyba 63.
- ciekawe są też róznice w wskazaniu ilości błędów, miedzy alfadiagiem a FES-em.
- kwp71 pokazał ilość taką samą jak alfadiag, tylko ta interpretacja bledów w kwp71 !!.
-Cytat:
Real Time Status Two
Parameter One
Central Unit Life Time Counting Starting From First Power On: 25 Minutes
Parameter Two
Number Of Times Powered On Counting From First Event Detected: 2
Cytat:
Real Time Status Three
Parameter One
Accelerometer 1: False
Accelerometer 2: False
Accelerometer 3: False
Battery 1: False
Battery 2: False
ASIC 1: False
ASIC 2: False
ASIC 3: False
Parameter Two
Microprocessor: False
Safety Sensor 1: False
Eeprom: False
Voltage Regulator: False
Driver Smart Led: False
Driver For Inhibition Loading Light: False
Safety Sensor 2: False
Cytat:
Real Time Status One
Fault Light, System Power Supply
System Fault Light: Light On
Battery Voltage < 10v for t>=100ms: Battery Voltage Ok
Type of Cabling Set Up: Open Switch (Driver Side Only)
Passenger Presence
Inhibition Switch Status Passengers Loading: Inhibition Not Requested
Passenger 1 Presence Status: Passenger Presence Found At Sensor 1
Passenger 2 Presence Status: Passenger Presence Not Found At Sensor 2
Passenger 3 Presence Status: Passenger Presence Not Found At Sensor 3
Inhibition Light Passengers Loading OFF/ON: Light Off
Detecting Baby Seat: Baby Seat Not Detected
Baby Seat Position: Unknown
Intervention Counters For Pretensioner And Side Airbags
Pretensioner Intervention Counter (in all max. 3 Volts): Zero interventions
Intervention Side Bags (Right and Left)(in all max. 3 Volts): Zero interventions
--
http://img443.imageshack.us/img443/6296/i012y.th.jpg
--
http://img689.imageshack.us/img689/7541/i016h.th.jpg
--
No dobra, a mógłbyś przełączać zasilanie tak dla testów? By całkiem wyeliminować mit o aku?
555,przekaznik, dwa stabilizatory (6v i 12v), kilka kondziorkow by w trakcie przełączania nie wyzerować całkiem zasilania i przełączać np. co 10sek.
Jak myślisz? bo teraz gdybamy,a już masz puchę na stole.
- sensor juz zawedrował do samochodu.
- ale czemu nie, na stole czeka jeszcze 4 sztuki do obróbki.
- ponizej wiertło do odkrecenia wkreta bez łba oraz zrzuty po zainstalowaniu poduszki oraz po resecie bledów.
--
http://img689.imageshack.us/img689/3...duszki1.th.jpg
--
http://img838.imageshack.us/img838/4...duszki2.th.jpg
--
http://img375.imageshack.us/img375/6425/wiertlo.th.jpg
--
- dalsze testy sensorów
- i jest mały problem, dla wersji sprzętowej 0.1 nie ma problemu z zerowaniem blędu 0x001 - "internal error".
- dla wersji sprzętowej 0.3 znane zawartości binarne plików nie zeruja licznika czasu, licznika odpalenia poduszki.
- powoduja także zapalenie nowego bledu 0x0000.
- może to jest spowodowane nowszym procesorem XC68 HC708AS60, maska dla tego procesora to 8H62A.
- znane zestawy listy sensorów twierdzą ze to sensor 60675876.
--
http://img837.imageshack.us/img837/1074/air026.th.jpg
--
http://img576.imageshack.us/img576/9350/air027.th.jpg
--
http://img820.imageshack.us/img820/3923/air028.th.jpg
--
http://img840.imageshack.us/img840/1971/air030.th.jpg
--
Może to przez organizację eeprom'a?
Oba procki mają pod tym samym adresem początek eeprom'a 0x0800 natomiast kończą się inaczej z powodu wielkości.
HC708 ma 640B, a HC908 tylko 512B. Oprócz tego inny jest sposób manipulacji zawartością pamięci.
Dwa procki niby podobne,ale nie są.
- dzieki, poszukam w tych linkach pliku odpowiedniego.
- tylko tam wszytkie albo 512 byte albo 1024 byte.
- 640 byte nie znalazłem.
Jak masz możliwość to aby sprawdzić czy różnica jest w zapisie na obydwu prockach i ich organizacji to musisz zrzucić z HC708 cały eeprom(640B) i jeśli po 512 bajcie jest jeszcze coś zapisane np. na końcu eeproma, suma kontrolna czy jakiś inny śmieć tzn.,że nie będzie tak łatwo z "binem" do tego uP i będzie trzeba szukać tego co ma 640B,a jak będą w eepromie same 0xFF po 512bajcie do samego końca to zostaję tylko kwestia programowa.
Szkoda, że w eepromie - tych plikach "bin" - nie ma sygnatury procka - by było fatwo sprawdzić jaki bin do jakiej grupy uP pasuję.
- autor programatora odpisał że mogę mieć problemy z tym procesorem.
- The MC68 HC708 AS60 is device identical to the HC908AS60 in its functionality and memory map, except for:
-- OPTflash ( one time programmable Flash).
- eeprom is 1 Kb ".
Z programatorami to mogę dorzucić od siebie tyle, że bardzo różnie bywa. Nawet te, które przychodziły do mnie razem z układem bezpośrednio od producenta krzemu nie dawały pełnej kontroli nad układem. Dla małych uP, a raczej mikrokontrolerów staram się programatory wykonywać... samodzielnie.
Na kolejnych seriach układów, nawet różniących się jednym numerkiem żerują producenci programatorów i soft'u. Nowszy układ = nowszy hardware i software = kasa. Jeśli ktoś ma obrót, nie ma czasu na wykonanie własnego interfejsu to po prostu go kupuje. Problem w tym, że serie przeznaczone na rynek automotive mogą być specyficzne, ciężej dostępne przez co także osierocone przez producentów programatorów, oprogramowania.
Fakt, są kombajny - jeden stoi 5 metrów ode mnie w biurze, zakupiła go firma dla której jestem podwykonawcą, moża za jego pomocą zrobić niemalże wszystko i to w CPU klasy ARM'a Cortex-A8. Minusem takich kombajnów jest niestety cena - wspomniany sprzęt ok. 17000 EUR, nową 159-tkę można kupić. Takie mini firmy jak moja raczej nigdy sobie na takie coś nie pozwolą, pozostaną z zasadą - nie zrobisz sam, nie będziesz miał.
P.S. Teraz Panowie pomyślcie co będzie się działo z nowymi, super wyposażonymi autami. Producenci aut zaczynają pchać bardzo skomplikowane układy, coraz szybsze o mocy obliczeniowej PC'ta. Chyba staje się jasne, dlaczego z każdą drobnostką w nowym super aucie trzeba jeździć do ASO, bo który z "cywilnych" zakładów zakupi specjalizowany komputer diagnostyczny na swoje potrzeby za ogromną kasę? Druga sprawa, dla ASO stanowi to niemały kąsek w postaci ekstra przychodów, być może że takim sprzętem diagnostycznym nie będą chcieli się dzielić...
- z programatorem nie mam problemów xprog-m daje sobie radę.
- problemy mam tylko z tym plikiem binarnym, T-Box, Carsoft, Tacho Pro, NYO4 nie widzą takiego procesora i nie bardzo chcą go zmodyfikować.
Tu masz szukany bin.
No i niestety też mnie dopadł 0001 po zwałce accu (to jedyny czynnik zewnętrzny jaki zaobserwowałem). Chwilowo nie mam czasu i sianka (bo zamierzałem w Cartoola zainwestować) na zajęcie się tym problemem więc mogę Ci Bubu podesłać centralkę po wystrzeleniu 2 czołowych (inna niż wspomniana powyżej). Będziesz mógł porównać zawartość z 0-crashowymi. Chcesz?
- pewnie,
- tylko w pierwszej kolejnosci podaj jaki numer ma ten twój sensor.
- a i dostałem także pliki do tego uprocesora Hc708AS60, bedzie można porównać na sensorze.
- wszystkie pliki jakie mam dla AS60 są rózne, to będzie ciekawie.
- z tym plikiem powyżej to sensor zadziałal na stole ale dopiero z interfejsem dla MY99, dziwne.
- jak bedzie wolna chwila to zobaczę ten drugi plik, zwłaszcza że się różni znacznie.
--
http://img835.imageshack.us/img835/3981/keyon.th.jpg
--
http://img686.imageshack.us/img686/9176/8003d.th.jpg
--
http://img826.imageshack.us/img826/9079/8007p.th.jpg
--
Tu masz foty:
http://picasaweb.google.com/sz3rsz3n/Airbag02#
Mogę wypruć jeszcze sensor z fotela, może się przydać.
- spawdziłem ten sensor.
- i chyba pasuje do podstawki ( czapka ) jaką pożyczyłem, jak chcesz to wysyłaj, zreprogramujemy.Kod:156 60655033 68HC08AS20
Chodziło mi o sprawdzenie, które pozycje się zmieniają przy wystrzale dwóch czołowych.
Mam jeszcze jeden - sprawdzę jaki i dam Ci znać.
- to będzie drożej kosztować !! ale jak ktoś jeżdzi alfą ...
--
http://img831.imageshack.us/img831/8...033g39y.th.jpg
--
Jak się bawicie wsadami do airbagów to mam jakiś programik o nazwie CAR_TOOL_1.06 jak ktoś jest zainteresowany to mu wyśle. No chyba że jego już macie. Tylko teraz wyczytałem że coś kiepsko daje sobie rade, oryginalny na klucz sprzętowy na usb a to jest jakieś shakowane.
- ten Airbag Tools ver 1.0 tez sobie daje radę, nawet poprawił pliki z 60655033, nie wiem czy na dobre.
- teraz to chyba nie ma problemu z sensorami starszych typów, nie ma konkurencji dla "naprawiaczy" w temacie starsze alfy.
- ale dzięki za zainteresowanie, zawsze warto zaoszczędzić te 75 zł na naprawę.
ten sterownik to, od jakiej alfy?Cytat:
Napisał bubu321
po Drawing No wychodzi, że od AR 147, ale wtedy plik 512.
System bag nie zadziała.
- zrzuty były robione z sensorów oznaczonych jako 60663943 na obudowie, czyli 156.
- możliwe że wgranie tej zawartości eepromu zmieniło Drawing i ISO code.
- w co osobiście wątpię, ponieważ to chyba jest wprogramowane na stałe.
a rodzaj procesora jaki jest?
Ten nr HC708AS60 odczytałeś z kości?
znane zestawy listy sensorów twierdzą, że w sensor 60663943 siedzi 68HC08AS20 MASK H94K.
No właśnie, zaczyna się mieszanie epromu z softem z eepromem z "licznikami".Cytat:
Napisał bubu321
- dane procesora HC708AS60 odczytałem z kości, maskę też 8H62A.
- data produkcji tego sensora to 2002 rok, czyli procesory z OTPflash.
- program airBag version 1 żle podaje numer procesora.
--
http://img829.imageshack.us/img829/8...ka8h62a.th.jpg
--
Jeżeli to XC68HC708AS60VFN, to wgraj bina, którego podałem w #57
Bubu - wyciągnąłem tą drugą. No i wygląda na to, że to chyba biały kruk 60658009.
- ja mam podane że 60658009 zastapiło stary sensor 60665492.
- jedno i drugie na HC08AS20, sensor firmy TRW.
- ta swoja puszke sensora z wersja 0.3 zaprogramowałem plikiem z #57, zrzuty ponizej.
- szkoda że podany plik nie kasuje licznika minut !!!
--
http://img843.imageshack.us/img843/58/28iso.th.jpg
--
http://img231.imageshack.us/img231/1...napshot.th.jpg
--
http://img840.imageshack.us/img840/6818/28fes1.th.jpg
--
http://img839.imageshack.us/img839/8916/28fes2.th.jpg
--
Podobno był bardzo krótko montowany.Cytat:
Napisał bubu321
- kolejne sensory 60658009, maska 0H94K, chyba na dwie poduszki, bo tyle jest kondensatorów w środku.
- czapka na uprocesor, odczytanie, zaprogramowanie i działa.
- sensor 60655033, maska 2G39Y, taki sam na dwóch kondensatorach.
- czapka na uprocesor, odczytanie , ....
- i tutaj kłopot, odczyt idzie do 90 % , i staje z komunikatem "Device not Responding".
- zapis eepromu idzie do 100%, zaś odczyt nie tylko do 90 %.
- blokada po crashu ?
--
http://img690.imageshack.us/img690/6869/r008r.th.jpg
--
http://img840.imageshack.us/img840/7347/r009.th.jpg
--
http://img340.imageshack.us/img340/4206/r011p.th.jpg
--
Przy weryfikacji jest ten błąd?
TAK.
- obecnie po wgraniu cleana wyczyszczonego za pomoca oprogramowania T-boxa sensor nie odpowiada.
- odlutowanie oporów na /IRQ i /RST nic nie daje, jest to samo.
- chyba pójdzie poszukac oryginału plików albo sensor uszkodzony.
Poczekaj poczekaj - tylko przy weryfikacji?
A sprawdzałeś po chwili przerwy(jakieś 3sek.) odczytać zawartość?
Weryfikacja jest natychmiastowa: zapis - odczyt.
A czy jak poczekasz chwile i dokonasz odczytu to jest ok?
Pamiętaj, że zapisujesz eeprom'a,a nie "głównego" flash'a i tutaj procedury zapisu są inne.
- odczyt, weryfikacja staje na poziomie 90% z podanym komunikatem.
- zapis idzie do końca ale po 2 - 10 sekundach podanie weryfikacji daje ten sam efekt, staje na poziomie 90 % z komunikatem podanym .
- poprzedni sensor poszedł bez problemu, czyli to nie problem z programatorem.
- maska jest inna w tym drugim, ale program podaje dobre security.