Problem z komunikacją HEX-CAN-USB

[sipowitz]

....I to wszystko, prościej się nie da opisać.

Zapomniałeś o procku kabla...

 

Powyżej opisana, zresztą szumnie nazwana "reanimacją" dotyczy tylko jednej części, tzn. tzw. układu FTDI odpowiedzialnego za identyfikację sprzętu w komputerze, pozostaje drugi element, procesor kabla, który wykonuje lwią część komunikacji na linii auto < komputer/program i często update uszkadza 1 bit w programie procka, co powoduje, że staje się on bezużyteczny. Dlatego wcześniej wspomniałem o jego programowaniu, a tutaj samo użycie kilku programów do "postawienia" FTDI i port USB nie posłużą do pełnego ponownego zaprogramowania. Co oczywiście nie zmienia faktu, że bardzo często FTDI jako pierwsze ulega "wywrotce".

 

Poza tym trzeba pamiętać o tzw. zabezpieczających fuse bitach dla procesora, ale to temat do głębszej analizy...

 

Poza tym pomylono pojęcia, wsady, dotyczą programu procesora, a tamte wsady, to nic innego jak zwykła konfiguracja FTDI, którą można wykonać chociażby z poziomu standardowego narzędzia jakie udostępnia firma FTDIchip dla swoich klientów. Dla zainteresowanych jest to MProg, którym spokojnie można wszystko "ręcznie" ustawić, bez konieczności zasysania, jak to wcześniej napisano "wsadów".

[Gość karl2222]

Witam Wszystkich.

Zakupiłem używany interfejs typu Hex+can 704.1 z laptopem. Sprzedawca zapewniał mnie że kabel jest oryginalny od adako. Poprawnie chodził na programie vag-com 704.1 który był zainstalowany na kupionym również lapku. Jednak nie dostałem od niego płyty z oprogramowaniem, więc pobrałem najnowszą wersję programu ze strony producenta. Po zainstalowaniu okazało się że zostałem oszukany , bo kabel się wysypał (nie łączyłem się z Internetem przy podłączonym fejsie, tylko najpierw ściągnąłem instalkę). Przerobiłem procedurę z Mprogiem i kabel ponownie jest wykrywany jako Ross-tech (na vag-com 704.1) nawet po podłączeniu fejsu do samochodu, jednak dioda na kablu świeci na czerowno nie na kolor zielony i dodatkowo podczas testu dolny komunikat: CAN NIE GOTOWY. Przy próbie sczytania jakichkolwiek błędów program przechodzi nieudane próby inicjalizacji can, dioda szybko miga na czerwono i żółto, a na końcu wyskakuje komunikat zbyt dużo błędów i sesja niestabilna. Czy powyższe objawy świadczą, że uszkodziła się również atmega i kto mógłby to ewentualnie naprawić ? Czy może to, że po ponownym postawieniu programu i kabelka test przeprowadzony był na modelu bez szyny can i pierwsze uruchomienie oraz test trzeba przeprowadzić na nowszym samochodzie z szyną.

[sipowitz]

Sądzę, że trzeba kabel na początek zaprogramować, ori instalator na 99% wywalił FTDI oraz procka. Trzeba moim zdaniem programować, aby przekonać się, czy przypadkiem nie siedzi również elektronika. Da się to zrobić, szczegóły na PM.

[Gość wojti23]

witajcie jestem nowy na forum szukam wsadu do interface vagcom hex can wersja pcb 6.25 potrzabny jest wsad do procesorów ATMEL 16V8BQL-15 , ATMEGA162 16AI ,93LC46 jesli ktoś chce mogę podrzucić to co posiadam

[makeć]

i dodatkowo podczas testu dolny komunikat: CAN NIE GOTOWY.

jeżeli auto nie ma CAN-a to i on będzie nie gotowy nie napisałeś jakie auto testujesz, bo pod awatarem nic nie masz.

Czy może to, że po ponownym postawieniu programu i kabelka test przeprowadzony był na modelu bez szyny can i pierwsze uruchomienie oraz test trzeba przeprowadzić na nowszym samochodzie z szyną.

nie ma znaczenia, test możesz wykonać nawet nie podłączając kabelka do auta i zapamiętać, po mimo, że wszystko było nie gotowe, przynajmniej tak zrobiłem przy swoim kabelku i w aucie już nie musiałem testować

polecam do naprawy kabli kolegę totalfree, niestety nie jest dostępny już na naszym forum, mam na niego namiar jak by co, a z kabelkami robi cuda.

Pozdrawiam

[arutim]

Witam Was drodzy użytkownicy;

Co prawda jestem nowy, zarejestrowałem się praktycznie tylko i wyłącznie[na początku] dlatego, że widziałem tam jednego DUMP'a pamięci 93, z nadzieją, że znajdę reszte wsadów... ponieważ masz na myśli popełnienie szatańskiego urządzenia to jest hex-can plus żywy zwykły kkl.

 

Przeczytałem cały ten wątek i widzę, że większość użytkowników trapi problem aktualizacji etc.

I o ile ATMEGę można zabezpieczyć bardzo łatwo przed niepowołanym zapisem [wystarczy kabelek na LPT i można ją śmiało programować, następnie we fuse należy wyłączyć programować ISP [in system programing] i ten problem już nas nie dotyczy] analogicznie pamięć 93 [tak mi się wydaje, że analogicznie jak 24cxx, ma nóżkę R/W,przez co [trzeba by spojrzeć do datasheet'u, podciągnąć ją do + lub gnd] o tyle nie mam koncepcji na konwerter RS< USB. Ale to każdy może sobie bez wyciągania kabelka z USB Mprogiem zaprogramować.

Dziwi mnie natomiast że kitajce tego nie blokują - choć zablokowanie programowania ISP zablokuje możliwość przeprogramowania atmegi... a to w przypadku jakiejś aktualizacji pociągnie za soba konieczność z korzystania z programatora równoległego a wtedy bez wylutowania układu się nie obędzie...............

 

 

Jeżeli chodzi o pierwsze dwa problemy - mam możliwości szerokiego manewru testowego [odpowiednie narzędzia programatory]. Mogę przygotować również sposoby programowania na tzw. partyzanta oraz zestaw narzędzi - problemem natomiast z mojego punktu widzenia jest dostępność wsadów...

 

Jeżeli ktoś jest zainteresowany podjęciem współpracy służę pomocą:

e-mail arutim małpa o2 [kropka] pl

[sipowitz]

Przeczytałem cały ten wątek i widzę, że większość użytkowników trapi problem aktualizacji etc.

I o ile ATMEGę można zabezpieczyć bardzo łatwo przed niepowołanym zapisem [wystarczy kabelek na LPT i można ją śmiało programować, następnie we fuse należy wyłączyć programować ISP [in system programing] i ten problem już nas nie dotyczy] analogicznie pamięć 93 [tak mi się wydaje, że analogicznie jak 24cxx, ma nóżkę R/W,przez co [trzeba by spojrzeć do datasheet'u, podciągnąć ją do + lub gnd] o tyle nie mam koncepcji na konwerter RS< USB. Ale to każdy może sobie bez wyciągania kabelka z USB Mprogiem zaprogramować.

Dziwi mnie natomiast że kitajce tego nie blokują - choć zablokowanie programowania ISP zablokuje możliwość przeprogramowania atmegi... a to w przypadku jakiejś aktualizacji pociągnie za soba konieczność z korzystania z programatora równoległego a wtedy bez wylutowania układu się nie obędzie...............

Jeżeli wyłączysz ISP jak zapewne wiesz stracisz możliwość "kontaktu" procesora z programatorem, wtedy tylko JTAG, ale to też pewnie wiesz... Jest prostszy sposób na aktualizacje, oszukanie DNSów. Poza tym, skąd masz pewność, że komunikacja aktualizacji odbywa się szeregowo?

mam możliwości szerokiego manewru testowego [odpowiednie narzędzia programatory]. Mogę przygotować również sposoby programowania na tzw. partyzanta oraz zestaw narzędzi

To nie jest już żaden problem, natomiast

problemem natomiast z mojego punktu widzenia jest dostępność wsadów...

stabliny wsadów dodałbym, krążą po świecie nawet wersje 908, ale wykonują wywrotki momentalnie.

[arutim]

Jeżeli wyłączysz ISP jak zapewne wiesz stracisz możliwość "kontaktu" procesora z programatorem, wtedy tylko JTAG, ale to też pewnie wiesz... Jest prostszy sposób na aktualizacje, oszukanie DNSów. Poza tym, skąd masz pewność, że komunikacja aktualizacji odbywa się szeregowo?

 

Wiem o JTAG, pisałem o tym kilka linijek ale wczoraj w nocy myślałem troszkę [przed snem na spokojnie] o tym wszystkim i brałem różne opcję pod uwagę i doszedłem do pewnych wniosków tj. że proc nie updatuje się przez ani jtag'a ani przez spi.. ale ogólnie.

Nie mam schematu więc nie mogę powiedzieć co jest dokładnie od czego, ani nawet spekulować, ale z tego co wiem to na płytce jest FT, Pamięć, atmega168 i kilka innych pierdołów - zapewne jakaś przetworniczka DC-DC i coś jeszcze - nie ważne na razie. Wybór przez producenta procesora atmega168 nie był przypadkowy, przecież można to było zrobić na tańszym i mniejszym chociażby atmega8 ale nie... bo producent wykorzystuje jedną ze specyficznych cech atmega168, Ci którzy zajrzeli do datasheet'u wiedzą co mam na myśli i wiedzą jakie jest tego zastosowanie. O co chodzi? A chodzi o to że patrząc wprost na kabel widzimy że wychodzi z niego jedna jedyna słuszna wtyczka USB, czyli proc komunikuje się "ze światem" za pomocą RS232 transkodowanego na usb... okej, a jak się programuje ? a no także przez rs232 i tutaj powinno zrodzić się pytanie yyyy jak to jest możliwe? A jest to możliwe i są 2 opcje:

bootloader został w pełni napisany przez producenta kabla i wrzucony na żywca w soft lub

dla ułatwienia producent wykorzystał właściwości mega168. To drugie ma zastosowanie bo gdyby nie, to mielibyśmy tutaj mega8 z odpowiednim softem. Ale wracając do bootloader'a to datasheet na początku mówi nam że:

Optional Boot Code Section with optional lock bits [to już powinno pocieszyć niektórych]

In System Programing by on chip boot program [niszczyciel kabelków:P]

Programming lock for software security - ta informacja powinna wywołać bananki:)

 

Delikatnie przeczytałem tego datasheet'a i na mój gust wypadałoby dorzucić fuse w:

blb02 "1" blb01 "0" - ta konfiguracja da "spm is not allowed to write to the app section

blb12 "1" blb01 "0" - ta natomiast zabezpiecza sam bootloader "spm is not allowed to write to bootloader section.

Dzięki temu nie tracimy możliwości update'u przez SPI i nie będzie wymagało to od nas drogiego programatora równoległego w przypadku gdyby chciało nam się zrobić update.

 

Co do samej pamięci 93Cxx to nie ma fizycznej możliwości zabezpieczenia tej pamięci przed skasowaniem - krótko mówiąc świetny wybór producenta kabla...

 

A możesz mi zdradzić kolego gdzie szukać tych wsadów? Wszak skądś musiały się wziąć skoro co po niektórzy programują nimi ubite kable...

Edytowane 10 Kwietnia 2010 przez arutim

[sipowitz]

doszedłem do pewnych wniosków tj. że proc nie updatuje się przez ani jtag'a ani przez spi..

Czyli jak?

Nie mam schematu

Napisz na PM, to Ci udostępnię do badań...

A chodzi o to że patrząc wprost na kabel widzimy że wychodzi z niego jedna jedyna słuszna wtyczka USB, czyli proc komunikuje się "ze światem" za pomocą RS232 transkodowanego na usb...

Dokładnie tak, rozwiązanie też uważam za przemyślane. Powiem Ci, że również OPCom jest zbudowany na bazie HEXa.

A jest to możliwe i są 2 opcje:

bootloader został w pełni napisany przez producenta kabla i wrzucony na żywca w soft

Dokładnie jest tak jak piszesz... Generalnie wsad (konkretnie eprom procka) pada po zmianie jestego bitu (nawet nie bajtu), do tego dodatkowo pada FTDI 93Cxx ale tutaj od strony (RS232/USB). Generalnie FTDI nie jest problemem, bo wystarczy przelutować pamięć na taką, która pozwoli zabezpieczyć zawartość poprzez zrobienie locka, o którym wspomniałeś wcześniej (lutnięcie jednej nogi). To już jest opracowane i działa w praktyce...

blb02 "1" blb01 "0" - ta konfiguracja da "spm is not allowed to write to the app section

blb12 "1" blb01 "0" - ta natomiast zabezpiecza sam bootloader "spm is not allowed to write to bootloader section.

Dzięki temu nie tracimy możliwości update'u przez SPI i nie będzie wymagało to od nas drogiego programatora równoległego w przypadku gdyby chciało nam się zrobić update.

Też tak kombinowałem, skutek był taki, że procek przestał pracować prawidłowo, czyli kabel przestawał się komunikować, niestety... Sprytne zabezpieczenie softowe w procku... Dlatego już wiesz dlaczego ping-pongi nie robią tych fusebitów.

Co do samej pamięci 93Cxx to nie ma fizycznej możliwości zabezpieczenia tej pamięci przed skasowaniem - krótko mówiąc świetny wybór producenta kabla...

Wystarczy podmienić na trudno dostępną pamięć 93CS46 i problem z głowy, bynajmniej z FTDI. Na szybko znalazłem jedno źródło: http://www.prodin.pl/p,19775,93cs46-smd-ulad-scalony.html

A możesz mi zdradzić kolego gdzie szukać tych wsadów? Wszak skądś musiały się wziąć skoro co po niektórzy programują nimi ubite kable...

Ależ oczywiście, ktoś zhaczył Atmegę (zdjął lub nie lockbity) i procek wypluł flash i eprom.

Edytowane 10 Kwietnia 2010 przez sipowitz

[arutim]

Czyli jak?

Programowanie typu ISP ale nie przez SPI tylko poprzez wbudowany bootloader wsad pobierany jest z rs232 w tym wypadku z usb poprzez ft transkodowany na RS. Zapewne całość się wykrzacza ze względu na inny bootloader w klonie i oryginale, ten z klona z racji że jest nie dopracowany zapewne czeka na coś innego, niż przesyła oryginał, leci jeden bit i proc przechodzi reset. I jest pozamiatane.

Napisał arutim Zobacz post

A chodzi o to że patrząc wprost na kabel widzimy że wychodzi z niego jedna jedyna słuszna wtyczka USB, czyli proc komunikuje się "ze światem" za pomocą RS232 transkodowanego na usb...

Dokładnie tak, rozwiązanie też uważam za przemyślane. Powiem Ci, że również OPCom jest zbudowany na bazie HEXa.

Ja uważam wręcz przeciwnie - rozwiązanie byłoby przemyślane gdyby była możliwość zablokowania możliwości zapisu do pamięci [chodzi mi o klona, bo producent oryginału nie zakładał klonowania przez co dla wygody swojej i użytkowników zrobili tak jak jest co jest rozwiązaniem po części sensownym].

 

Cytat:

Napisał arutim Zobacz post

blb02 "1" blb01 "0" - ta konfiguracja da "spm is not allowed to write to the app section

blb12 "1" blb01 "0" - ta natomiast zabezpiecza sam bootloader "spm is not allowed to write to bootloader section.

Dzięki temu nie tracimy możliwości update'u przez SPI i nie będzie wymagało to od nas drogiego programatora równoległego w przypadku gdyby chciało nam się zrobić update.

Też tak kombinowałem, skutek był taki, że procek przestał pracować prawidłowo, czyli kabel przestawał się komunikować, niestety... Sprytne zabezpieczenie softowe w procku... Dlatego już wiesz dlaczego ping-pongi nie robią tych fusebitów.

Swoją drogą wolałbym to sprawdzić osobiście, bo trapi mnie jeszcze jedna rzecz tj. czy ten procesor oby napewno potrafi odczytywać swoje fuse spod poziomu flash'a - zresztą złoże to sprawdzę - może pomyliłeś się przy liczeniu fuse? Czym programowałeś?

Cytat:

Napisał arutim Zobacz post

A jest to możliwe i są 2 opcje:

bootloader został w pełni napisany przez producenta kabla i wrzucony na żywca w soft

Dokładnie jest tak jak piszesz... Generalnie wsad (konkretnie eprom procka) pada po zmianie jestego bitu (nawet nie bajtu), do tego dodatkowo pada FTDI 93Cxx ale tutaj od strony (RS232/USB). Generalnie FTDI nie jest problemem, bo wystarczy przelutować pamięć na taką, która pozwoli zabezpieczyć zawartość poprzez zrobienie locka, o którym wspomniałeś wcześniej (lutnięcie jednej nogi). To już jest opracowane i działa w praktyce...

Ta atmega ma "tylko" 16kB kodu, obawiam się że zdeasemblerowanie kodu a następnie analiza i samo znalezienie miejsca w którym soft sprawdza stan fusebit'ów i zamienienie tego jednego słusznego bitu nie będzie jakimś szczególnym problemem mając gotowe urządzenie na biurku - mogę się podjąć tych badań, tylko wpierw muszę zbudować sprzęt. Jakieś wsady już znalazłem i zachodnich kolegów więc najgorsze powiedzmy już mam, teraz reszta materiałów i mogę brać się do roboty.

Napisał arutim Zobacz post

Co do samej pamięci 93Cxx to nie ma fizycznej możliwości zabezpieczenia tej pamięci przed skasowaniem - krótko mówiąc świetny wybór producenta kabla...

Wystarczy podmienić na trudno dostępną pamięć 93CS46 i problem z głowy, bynajmniej z FTDI. Na szybko znalazłem jedno źródło: http://www.prodin.pl/p,19775,93cs46-...d-scalony.html

Tutaj, można byłoby spróbować zastosować "tańszy" manewr w postaci obniżenia napięcia zasilania samej pamięci [rezystorek szeregowy i zenerka - wtedy czysto teoretycznie pamięć nie mogłaby się skasować a odczyt szedł by prawidłowo - ale to można stwierdzić tylko eksperymentalnie.

Przyszedł mi szatański pomysł do głowy hehe żeby dorzucić jeszcze jedną atmegę do tego układu, która by:

monitorowała 93cxx i w przypadku zmian programowała ją tak jak trzeba, oraz monitorowała wsad do drugiej atmegi i w przypadku wykrycia zmian przywracała odpowiedni soft...

Choć tą małą pamięć można podmienić na inną lub zastąpić małym prockiem który emulował by tą pamięć skutecznie zabezpieczając przed zapisem... ale to temat do przemyślenia.

 

Swoją drogą, skoro klucz jest w atmedze, można by zastosować inny transkoder rs<>usb dzięki czemu z definicji byłby odporny na zapis... ale to też do obadania;)

[sipowitz]

Swoją drogą wolałbym to sprawdzić osobiście, bo trapi mnie jeszcze jedna rzecz tj. czy ten procesor oby napewno potrafi odczytywać swoje fuse spod poziomu flash'a - zresztą złoże to sprawdzę - może pomyliłeś się przy liczeniu fuse? Czym programowałeś?

Generalnie założyłeś, że będziesz miał dostęp do wsadu (flasha i eproma) sprawdzonego, jednak pamiętaj, że trzeba go wyłuskać. A jak pewnie wiesz na założonych lockbitach żdnego fusa nie zmienisz. Co do ich odczytu z poziomu flasha, nie mam takiej wiedzy. Pomylić się trudno, bo są narzędzia, które to ładnie liczą. Na piechotkę to tylko siusiu...

Ta atmega ma "tylko" 16kB kodu, obawiam się że zdeasemblerowanie kodu a następnie analiza i samo znalezienie miejsca w którym soft sprawdza stan fusebit'ów i zamienienie tego jednego słusznego bitu nie będzie jakimś szczególnym problemem mając gotowe urządzenie na biurku - mogę się podjąć tych badań, tylko wpierw muszę zbudować sprzęt. Jakieś wsady już znalazłem i zachodnich kolegów więc najgorsze powiedzmy już mam, teraz reszta materiałów i mogę brać się do roboty.

Szczegóły możemy omówić na PM.

Tutaj, można byłoby spróbować zastosować "tańszy" manewr w postaci obniżenia napięcia zasilania samej pamięci [rezystorek szeregowy i zenerka - wtedy czysto teoretycznie pamięć nie mogłaby się skasować a odczyt szedł by prawidłowo - ale to można stwierdzić tylko eksperymentalnie.

Masz pewność, że przy tak niskim progu pamięć będzie pracować właściwie. Zastanów się, co się stanie, jeśli nagle VCDS stwierdzi podczas kodowania w aucie, że kabel jest unlicensed i w połowie całość stanie? Moim zdaniem ryzykowne rozwiązanie.

Przyszedł mi szatański pomysł do głowy hehe żeby dorzucić jeszcze jedną atmegę do tego układu, która by:

monitorowała 93cxx i w przypadku zmian programowała ją tak jak trzeba, oraz monitorowała wsad do drugiej atmegi i w przypadku wykrycia zmian przywracała odpowiedni soft...

Ciekawy pomysł, generalnie wiesz jak zrealizować samokopiowanie z jednej do drugiej? Pomysł chyba zaczerpnięty od producentów płyt głównych do PC, tam też bywają podwójne biosy, po starcie moża przefleszować z dobrego na uszkodzony.

Choć tą małą pamięć można podmienić na inną lub zastąpić małym prockiem który emulował by tą pamięć skutecznie zabezpieczając przed zapisem... ale to temat do przemyślenia.

Moim zdaniem zbyt duży nakład pracy i środków na tak proste rozwiązanie jakim jest zastąpieniem na 93cs46.

 

Ja zająłbym się inną kwestią, mianowicie aktualizacjami, czyli poszukałbym miejsca gdzie i jak updatuje się soft (debug i analiza wsadu) w kablu do wyższych wersji puściłbym update z sieci. Generalnie miałem pomysł, że "posłuchać" lecących pakietów z ross-tech.com, ale siły i chęci mnie opuściły. Wtedy klonik byłby doskonały...

[arutim]

Generalnie założyłeś, że będziesz miał dostęp do wsadu (flasha i eproma) sprawdzonego, jednak pamiętaj, że trzeba go wyłuskać. A jak pewnie wiesz na założonych lockbitach żdnego fusa nie zmienisz. Co do ich odczytu z poziomu flasha, nie mam takiej wiedzy. Pomylić się trudno, bo są narzędzia, które to ładnie liczą. Na piechotkę to tylko siusiu...

 

Zakładam, że wsady którymi ludzie ratują kable są w porządku do organoleptycznego stwierdzenia czy soft zmienia sobie na live wartości we flashu nawet wsad który będzie działał 5minut mi wystarczy - będę później wiedział czego się czepić.

Masz pewność, że przy tak niskim progu pamięć będzie pracować właściwie. Zastanów się, co się stanie, jeśli nagle VCDS stwierdzi podczas kodowania w aucie, że kabel jest unlicensed i w połowie całość stanie? Moim zdaniem ryzykowne rozwiązanie.

Jeżeli ta pamięć jest tylko do FT, a o tym wspominałeś, nie mam schematu by to potwierdzić, to zawarta w niej jest konfiguracja tegoż układu, odczytywana jednokrotnie podczas inicjalizacji USB [podczas wykrywania i rozpoznawania urządzenia poprzez windows] zapewne później już nie jest wymagana do normalnej pracy... zresztą to można sprawdzić dając jakiś mały przełącznik pomiedzy + a jej Vcc i po połączeniu odłączając jej napięcie - jak fejs się zresetuje to znaczy że korzysta z niej na bieżąco, jak nie to nie i mamy wolną drogę.

 

Ciekawy pomysł, generalnie wiesz jak zrealizować samokopiowanie z jednej do drugiej? Pomysł chyba zaczerpnięty od producentów płyt głównych do PC, tam też bywają podwójne biosy, po starcie moża przefleszować z dobrego na uszkodzony.

Mam na to koncepcje - wymagać to będzie dołożenia jednej kostki i jakieś małego uP, sumaryczny koszt - włącznie z laminatem poniżej 10zł, pamięci mają nóżkę CS - ChipSelect, a sama atmega spi i bootloader ktoremu można by się przyjrzeć - jest wiele możliwości

Moim zdaniem zbyt duży nakład pracy i środków na tak proste rozwiązanie jakim jest zastąpieniem na 93cs46.

 

Ale dzięki takiemu rozwiązaniu interfejs mógłby stać się bardzo edukacyjnym tj.

np. w jednym kablu mogłyby by być fejsy pl/en i inne... a i sam fejs byłby nie śmiertelny tj np. jedno kliknięcie przyciskiem i mamy spowrotem żywy fejs bez rozkręcania etc.

Także dzięki takiemu rozwiązaniu fejs byłby nie zależy od pc - nawet omyłkowe podpięcie do innego komputera z włączonymi aktualizacjami...

Ja zająłbym się inną kwestią, mianowicie aktualizacjami, czyli poszukałbym miejsca gdzie i jak updatuje się soft (debug i analiza wsadu) w kablu do wyższych wersji puściłbym update z sieci. Generalnie miałem pomysł, że "posłuchać" lecących pakietów z ross-tech.com, ale siły i chęci mnie opuściły. Wtedy klonik byłby doskonały...

Rosstech na pewno mocno nakombinował jeżeli chodzi o autoryzację kabla, założę się że sam ross-tech podczas aktualizacji kabla loguje jego ID i IP, później automat z definicji sprawdza dany ID kabla - jeżeli np. było kilka aktualizacji tego ID kabla - leci na czarną listę - dziękuje i dowidzenia...a wtedy program ross-techu sam wie co robić...

Edytowane 10 Kwietnia 2010 przez arutim

[siegrze4]

Witam.

Czy możesz podesłać mi plik FA24_RT000001=Ross-Tech HEX-USB_232bm.ept?

Z góry dziękuję.

[sipowitz]

Zczytaj sobie ze zdrowego, tam masz wszystkie ustawienia MProga.

[siegrze4]

Chętnie bym to zrobił ale są dwa problemy:

po pierwsze nie mam zdrowego,

po drugie bałbym się czytać mprogiem żeby czegoś nie uwalić

 

---------- Post added at 06:50 ---------- Previous post was at 06:46 ----------

Edytowane 16 Kwietnia 2010 przez siegrze4
Podwójna wypowiedź

[kropeck]

Wsady do kabli są dostępne na rosyjskich forach internetowych. Oczywiście wtedy tylko wersja EN oprogramowania.

[arutim]

Witam.

Czy możesz podesłać mi plik FA24_RT000001=Ross-Tech HEX-USB_232bm.ept?

Z góry dziękuję.

 

Która wersja kabla ?

 

witam czy ma ktos sprzedac kabel softa juz mam 908,2 a kabla nie chce kupowac na ebayu bo tam duzo bubli jest

 

pisalem juz yasska jakis czas temu ale nie mam zadnej odpowiedzi

 

albo przynajmniej doradzcie co i gdzie kupic

Skoro softy masz to:

http://www.tme.eu/pl/, płytkę sam możesz wytrawić [daje radę zrobić to na jednostronnej] i masz kabel taki jaki zrobisz - jak się postarasz to nie wyjdzie bubel ;P

 

 

///

Pytanie za 1000 punktów

Czy posiada ktoś dowolny wsad do EEPROMU atmegi do polskiej wersji i chciałby się nim podzielić??

Edytowane 1 Maja 2010 przez arutim

[arutim]

Wyniki 'wstępnych' badań nad HEX'ami:

Generalnie interfejs 'da się' zabezpieczyć przed 'uwaleniem' softu poprzez fuse-bity ATmegi.

Baaa odpowiednio manewrując podczas aktualizacji innymi fusami [między innymi od bodlevel oraz taktowania startup time etc] da się zaktualizować fejs poprzez wbudowany w VCDS mechanizm aktualizacji... nie wiem czy ten fejs który dostałem do badań od kolegi Sipowitz jest ori czy ja coś tak mocno nakręciłem, że to nawet zadziałało i nie ubiło fejsu...

Tylko raz - podczas mocnego manewrowania z polską wersją udało mi się 'uśmiercić' interfejs - co mocno mnie zdziwiło, bo na setkę prób i kombinacji tylko jeden tego typu 'kwiatek'.

Prze okazji doszedłem do pewnych wniosków - wsad z flash'em praktycznie od ręki mamy w katalogu z Vag-comem/vcds'em/ gorzej jest z wsadem do EEPROMU atmegi ... ale zauważyłem że VAG pod pewnymi adresami zapisuje sobie 'ilość' uruchomień danego interfejsu. Z tego co doczytałem niektórzy mieli problemy [na jakimś anglojęzycznym forum] z wersjami beta które uruchamiały się maks 20razy [klony z ebay'a].

 

Swoją drogą jest narzędzie które pozwala odczytać zablokowaną przed odczytem atmegę - nazywa się xprog-m [i nie tylko zablokowaną atmęgę - w poszczególnych pakietach to jest niezły kombajn tylko ta cena...]

[sipowitz]

Czy posiada ktoś dowolny wsad do EEPROMU atmegi do polskiej wersji i chciałby się nim podzielić??

No oczywiście...

Generalnie interfejs 'da się' zabezpieczyć przed 'uwaleniem' softu poprzez fuse-bity ATmegi.

Mi niestety się nie udało... Ale chętnie poznam szczegółowy mechanizm działania i konfigurację.

gorzej jest z wsadem do EEPROMU atmegi ...

Leci jako updeate podczas aktualizacji kabla.

Swoją drogą jest narzędzie które pozwala odczytać zablokowaną przed odczytem atmegę - nazywa się xprog-m [i nie tylko zablokowaną atmęgę - w poszczególnych pakietach to jest niezły kombajn tylko ta cena...]

Jeżeli mówimy o 500 zł to chyba nie tragedia...

[arutim]

Cytat:

Napisał arutim Zobacz post

gorzej jest z wsadem do EEPROMU atmegi ...

Leci jako updeate podczas aktualizacji kabla.

 

Niestety kolego ale nie leci update eepromu - w eepromie przechowywanych jest w chytry sposób kilka rzeczy - między innymi licznik uruchomień.

Zrobiłem mniej więcej taki myk - wrzuciłem w atmegę fuse [security C0] czyli wszystko zablokowane przed odczytem / zapisem [z punktu widzenia bootloadera i komputera po kablu FT232]. Odpalilem VCDS który krzyknął mi że ma hex'a ale nieznana wersja softu i trzeba zaktualizować [w tym miejscu trzeba dodać że jak miałem narąbane w LowFuse, to pokazywało mi wersję 0,71 a nie 1.71...(wersja przykladowa)] klikam mu okej i czekam - przełączam się na programator avr [spi cały czas podpięte] wrzucam od nowa soft w procka tylko bez eepromu [przy kompletnym zablokowaniu atmegi nie można zmienić samego lock-bit'a trzeba wrzucić wszystko raz jeszce. Programuje i odpalam aktualizacje w VCDS - aktualizacja leci... po chwili znika i kabelek się uruchamia - krzycząc że nie przechodzi testu własnego... - w eepromie pojawia się kilka maluśkich rzeczy - np po aktualizacji zmienia się bit z ff na 02 pod adresem 000018 bit nr 03 [w oryginalnym wsadzie w tym miejscu jest ff, w pustym zresztą też] pod tym samym adresem a w bitach 04 05 06 07 jest zapisany licznik uruchomień - po jego przepełnieniu się zeruje - więc dla zwykłego user'a jest to praktycznie bez znaczenia [mówimy tutaj o release a nie beta].

 

Jeżeli chodzi o programator...

http://www.tmt.lt/Files/Xprog_m_pricelist.pdf

 

To conajmniej 250Euro... czyli tysiak - no chyba że kupić chińskiego klona.... ;D