Tryb drzewa | Tryb normalny

SQ9RFC · 08-01-2019 10:26

Klon PICKIT2 z AVT przerobiony przeze mnie bo mia błąd.
Setki jeśli nie tysiące programowań...
PIC16F628A nówka z allegro - kilka sztuk kupione ze 2 lata temu.
Zaprogramowany dawno - trzeba było wpisać nowy soft, no i było ok.
Programowanie w układzie - do linii programowania nic nie podpięte - prosty projekt.
Nagle procek? programator? strajkuje - weryfikacja przeszła a układ nie działa ... pewnie błąd programu... wracam do poprzedniej wersji ... nie przechodzi weryfikacji ... nagle programator nie rozpoznaje procka ! Jest podstawka więc procka wydłubuje i wkładam do oddzielnej podstawki, podłączam programator - poszło. Myślę ki czort. Ale jestem zadowolony bo układ działa ... ale to stabilna poprzednia wersja :-( Zmieniam HEX i ... sytuacja się powtarza !!! nie mam czasu więc znów wydłubuję - ładuję stary HEX i ... nawet w zewnętrznym programatorze nie identyfikuje procka !!! Nic nie pomaga. Myślę procek padł, szkoda. Nowy - znów zewnętrzny programator i stary HEX. Działa. Procek już w układzie, wiec nowy wsad i ... dupa !!!!!! wszystko się powtarza. Nawet na zewnątrz nie rozpoznaje ... Idę spać.

(cd w następnym poście bo jest ograniczenie ilości jednorazowego tekstu ...)

cd...
Dziś rano ściągnąłem inne oprogramowanie do programatora - poprzednio było MPLAB IDE v8.92 teraz PICkit2 v2.61 w tym nowym oprogramowaniu można ustawić automatyczne rozpoznawanie procesora - i ... rozpoznał te "padnięte", ale nie do końca. Nie chcą się wykasować, ale czasem czyta zawartość ! Często znów nie rozpoznaje ... Nagle wykasował i przeszły wszystkie testy! Wpisałem tę działającą wersję HEXa i wszystko OK !!!! Nie do końca :-( Stary soft działa to dawaj nowy ... testy przeszły, ale wszystko znów szlak trafił ... nic nie rozpoznaje, nic nie widzi, a godziny mijają ... DUPA ! Przeleciałem oscyloskopem wszystkie sygnały programatora - wydaje się że jest OK ! Tam jest przetwornica do Vpp - ale chyba wydala - wieczorem podam tam normalne 12V z innego zasilacza.
Teraz pytanko ... co jest grane? Te procesory nie maja przecież zabezpieczenia przed skasowaniem pamięci ! Jakaś felerna partia ? Zamówię te procki - pomimo że na nich się już mało robi. Gdyby ktoś miał na zbyciu PICKIT2 albo PICKIT3 oryginalne to bym kupił.

SQ8MVY · 08-01-2019 13:28

Witaj,

Oryginalny PicKit4 - czyli najnowszy, jest obecnie tańszy od starszego PicKit3. ( ceny z farnella )

Cena w farnellu niewielka - 143pln netto - więc nie warto sobie zawracać głowy podróbkami, jeżeli na co dzień pracujesz z prockami Microchipa.

Dostępny jest też w Botlandize, ale cena jest kosmiczna.

PicKit4

SQ9RFC · 09-01-2019 0:00

PICKIT4 zamówiłem i garść procków, a 2 i 3 z drugiej ręki są po kilkanaście zł. Podróbka/samoróbka, jeśli się rozumie jak działa jest lepsza od oryginału. PICKIT2 jest prosty w budowie i użyciu. Mam jeszcze prostszy programator na RS232 - to dopiero łopatologia. Kilka linijek własnego programu i można kontrolować wszystko - tyko kwestia czasu. Pytanie brzmi: "Co jest grane ?". Dziś już nie mam siły - może jutro wygospodaruje trochę. Procki i programator powinien być na czwaartek/piątek. Już się kiedyś spotkałem z podobnym problemem. Procek strajkował, nie chciał się programować kilka razy z rzędu, ale po wystudzeniu problem znikał. trzeba sprawdzić.

Poranne wiadomości - coby forum żyło ... i było co poczytać przy kawce... W nocy przerobiłem wszelkie kombinacje różnych programatorów... bezskutecznie - ale układy żyją, bo widać na przyrządach, że wsad przynajmniej w pewnej części działa. Znalazłem trzeciego procka 628, zaprogramował się bez problemu ... ale tamtym nie odpuszczę ! Muszę poszukać czy nie ma jakiś ukrytych i niepublikowanych właściwości tego układu, które na przykład ustawione nie pozwalają nawet na skasowanie zawartości - byłoby to rozsądne ... takie zabezpieczenie ... przed głupotą Pamiętam, że pewna seria Z80 mia całą masę niepublikowanych komend i funkcjonalności.

SQ9RFC · 17-01-2019 12:16

:-) Uśmiałem się do łez ...
Aby znaleźć przyczynę blokowania PICków. Sprawdziłem w *.asm różnice pomiędzy działającym i nie działającym - tylko 3 linijki zmienione ...
Nowego wykasowałem, przetestowałem, skompilowałem nową wersję i zaprogramowałem w zewnętrznym programatorze. Efekt ? .... :-) znów totalna blokada :-)))))
Porównałem piki *.hex ... i tu zagwozdka ... powinny być zmiany w 2 bajtach pamięci !, a w porównywarce aż czerwono od różnic ...
No i zaczynam się powoli domyślać co jest grane ...
Prawdopodobnie pokombinowane jest coś z literka A na końcu nazwy picka. A PIC16F628A to nie to samo co PIC16F628 !
Skompilowane na wersję A, a wgrane tak jak by nie było A, albo na odwrót... pójdę tym tropem...
Czyżby nie było żadnej ochrony pewnych obszarów pamięci ?

SP9FYS · 17-01-2019 17:30

Jestem kompletnie zielony ale ponieważ zaczynam się powoli późno, bo późno uczyć , czytam nawet to co nie bardzo rozumiem.
Producent dawno wydał notę o różnicach.Może to będzie przydatne:
http://ww1.microchip.com/downloads/en/De...40048a.pdf
73! R.

SQ9RFC · 18-01-2019 11:58

Dzięki. Znam to.
Fascynuje mnie jak podczas programowania można zablokować PICka. Te procki tego nie mają ! Nawet zabezpieczone przed kradzieżą zawartości - dają się wykasować do stanu dziewiczego ...
MPLAB przestaje je rozpoznawać, bo nie jest w stanie odczytać jego ID, a więc dziś z rana oszukałem MPLAB - znalazłem gdzie przechowuje ID procków i zmieniłem na taki jaki jet odczytywany z tych zablokowanych. I teraz MLAB je rozpoznaje :-) i próbuje kasować - ale nieskutecznie.
Aha ... programator jest ok, bo programuje niezablokowane procki z tej rodziny, na wszelkie sposoby.
Przelecę dokładnie różnice w adresowaniu pamięci tego działającego i blokującego programu ...
Na forach piszą o napięciach zasilających podczas programowania. Sprawdzone, przetestowane - to nie to.

WIKTG · 18-01-2019 20:40

Po moich ostatnich doświadczeniach z programowaniem PIC16F88 i próbami ich wykasowania, dochodzę do wniosku, że "jakieś wyższe siły" prawdopodobnie wprowadziły pod "F" wersję OTP, czyli jednokrotnie programowalną i stąd te problemy.

SQ9RFC · 18-01-2019 23:08

Myślę, że to nie to w tym przypadku, bo te procki były wielokrotnie programowane. Ja myślę że podczas prób gdzieś coś pozmieniałem za szybko i wymusiłem zapis w obszarze ważnego a nie chronionego obszaru pamięci. MPLAB jest dość mało inteligentny. Nie miałem czasu jeszcze porównać kodu i sprawdzić gdzie on to zapisuje. Skupiłem się na razie na wymuszeniu wykasowania. Czuje, że wiem co się stało, ale na spokojnie i powoli muszę to sprawdzić.

KLIMA · 20-01-2019 16:48

Wiesz co, wydaje mi się, że to nie ma sensu. Masz po prostu uszkodzone procesory.
Kup nowe, a te wywal. Wierz mi, taka zabawa nie ma sensu.

SQ9RFC · 20-01-2019 17:51

Nie masz racji. Ma to sens, bo zabawa jest w łapaniu króliczka. Równie dobrze mógłbym kupić fabryczne radio - wiesz ile bym zaoszczędził czasu i pieniędzy !
Te procki nie są uszkodzone. One są tyko jakoś sprytnie zablokowane. Robi to mój program. Jeszcze raz przypomnę sekwencję zdarzeń.... wkładam nowy procesor - dla testów wpisuje i kasuje różne programy, aby sprawdzić czy wszystko jest z nim ok. Potem wpisuje mojego hexa... Zapis jest bezbłędny, bo po zaprogramowaniu natychmiast przechodzi test czy to co jest wgrane jest tym co miało być wgrane. Kończą się testy, procek startuje i od tego momentu przestaje być rozpoznawany przez programator. Program w nim zawarty częściowo działa, chodzi główna pętla programu, niepoprawnie reaguje na sygnały wejściowe, generuje niepoprawne sygnały wyjściowe, ale reaguje ... więc żyje. Mam kupić karton procesorów i za każdą zmianą programu zastanawiać się czy coś jeszcze zostało w pudełku ? :-) To nie jest program napisany przez kogoś innego - to mój program i ja go będę zmieniał i wgrywał jeszcze setki razy ... Dla ścisłości - jeszcze nie grzebałem w kodzie, więc z mojej strony nic nowego.