Microchip PIC16C54 - disassembler

Jul 25, 2003 19 Replies

Czy mo¿ecie poleciæ jaki¶ w miarê dobry i darmowy disassembler do procka PIC16C54? Przerabiam sobie w³a¶nie serwo, taki kontroller do zaworu wodnego i chcia³bym zerkn±æ na oryginalny kod. Wylutowa³em scalak, by³a to zwyk³a obudowa DIP18 (scalaczek to PIC16C54-RC/P) i mam binarkê z kodem... O dziwo - chyba nie jest zablokowana, bo jest tam co¶ wiecej ni¿ 00/FF. P³yteczka jest pro¶ciutka - ³atwo siê zorientujê który port do czego :-)



Czy jest jakie¶ narzêdzie w sieci, które zrobi mi z tego jaki¶ asm/lst?



BTW - czy ja dobrze czytam na witrynie microchipa, ¿e ten CPU ma tylko 512 dwunastobitowych komórek pamiêci na kod programu? Je¶li tak, to mo¿e ja sobie ten kod rozkodujê rêcznie? :-)


Recznie nie recznie. Instrukcja ma stala dlugosc weic mozesz zrobic prosta konwersje liczby 12 bitowej na ciag znakow. Moze przesadzilem ze to wszystko tak prostto ale mozna napisac prosty programik alebo makrosy do edytora takie porobic ze ci konwersjhe zrobi. Ale dizassemblery pewnie jakies sa.

Pozdro Grzechu

W edytorze programatora EMP11 bufor wygl±da³ jakby co drugi bajt by³ 0. Mo¿e te 12 bitów rozk³adaj± na dwa bajty... Nie wiem... A jak w ogóle wygl±da odczytywanie zabezpieczonego PIC16C54? Czy wtedy ma wszystkie 00/ff czy mo¿e pokazuje "g³upoty"?

No w³asnie chodzi mi o to, ¿e jako¶ trudno mi je znale¼æ... Znalaz³em parê zintegrowanych ¶rodowisk programistycznych, ale dzia³aj± raczej w drug± stronê, t± "normaln±", od asm->hex. Szukam czego¶, co z binarki zrobi mi asm.

No normalnie to powinien powiedziec "porcek zbezpieczony i przeczytac nie moge" Jezeli tak nie pisze to albo sie wogole nie nadaje albo nie jest zabezpieczony.

Jezeli program prosty i krotki to bym zrobil tak. Hajpierw z binarnego przeroil na hex zeby widzoec mniej wiecej co to jest. Mozesz zreszta wczytaz a potem zsejwowac na plik typu Intelhex czy MotorolaHex A potem rozpoznac czy sie cos to jakos trzyma kupy. Czy tam grdzi esie zczyna program jest co trzeba.

No a potem robilbym suctytucje zadzanych sekwencji na instruikcje z mnemonikiem i ew argumentem w postaci cyfrowej. Potem bym zobaczyl ktore adresy jak sa uzywane i przerobil na jakies adresy symboliczne. RObilem juz tak czasem. Niestety MPLAB wogole nie robi dizasemblcji a le jakos ciagnie po kodzie zrodlowym. Osobiscie tego nie lubie bo cokolwiek chcesz zmienic to musisz kompilowac na nowo. Niemowiac ze nie lubie takich zintegrowanych srodowisk bo sam lubie tworzyc programy modularnie z wielu plikow zrodlowych i MPLAB slaby do tego jest juz nie mowiac o edytorze kotry jest kompletnie do dupy. Jak ktos programowam pisza tesxt a pmoca Notepad to moze to uzna za dory ale ja juz od przwie 20 lat uzywam najpierw Brief'a a teraz CodeWright i mam pewne wymagania. A niestety MPLAB slabo wspolpracuje z czymkolwiek innym.

Ciekaw jestem jak sie zachowuja inne Emulatory do PICa Znaczysie MPLAB to o ile pamietam nie jest emulator ale software a emulator z Microchipa ma jakas inna nazwe (nie chce mi sie teraz sprawdzac)

Co Ty uzywasz Pszemolku ?

Pozdro Grzechu

W buforze programatora 12-bitowe s³owo programu bêdzie widziane jako 2 bajty. Je¿eli s± inne warto¶ci ni¿ 00h lub FFh to jest szansa ¿e procek niezabezpieczony.

MPLAB (5.70)

  1. Options > Development Mode > Tools > wybraæ PIC 16C54
  2. File > Import > Import To Memory > wskazaæ plik [*.hex]
  3. Window > Program Memory

no mo¿e etykiet nie bêdzie ale mnemoniki byæ powinny ...

szkoda czasu ;)

co robi? 8)

Kwestia przyzwyczajenia. Zreszt± po co u¿ywaæ zewnêtrznego edytora jak jest zintegrowany pozwalaj±cy na ¶ledzenie programu w tym samym oknie.

Zaawansowane sprzêtowe s± bardzo dobre.

pzdr jmdsh

Wys³a³em do Ciebie e-mail ale mi siê odbi³ z b³êdem... Chcia³bym Ci wys³aæ ten bufor i prosiæ o przerobienie na asma lub chocia¿ sensownego hexa którego móg³bym u¿yæ. Wygl±da na to, ¿e siê znasz na tym i nie sprawi Ci to problemu... Czy zechcia³by¶ mi pomóc?

File > Export > Export Memory > wpisaæ nazwê pliku [*.txt] (zaznaczyæ "kod po dezasemblacji")

Pokazuje w oknie {Program Memory} - daje siê ¶ledziæ ale nie daje zmieniaæ. Aby co¶ zmieniæ trzeba poprawiæ w listingu (zintegrowany edytor!) i skompilowaæ (jeden klaiwsz) jak siê ma emulator to nowy kod ³aduje siê automatycznie. Potem siê uruchamia i korzysta z pu³apek (ustawiane w {Debug} na etykietê nie s± gubione przy rekompilacji)

Dla mnie wa¿ne s± po¿±dne kopiuj/wklej/szukaj/zamieñ, automatyczna tabulacja, wskok do lini kodu z b³êdem i oczywi¶cie integracja z debuggerem. Reszta to zbytek. Spróbuj narzêdzi IAR np do MSP430 to jest dopiero tragedia (ju¿ 3K linii za mn± ;) Mam listing w asm do PICa na 8KB (ok 9900 linii) napisany w ca³o¶ci MPLAB ;)

Do Microchipa to tylko firmowych ICE2000 i ostatnio ICD2. Ten pierwszy jak dot±d najlepszy emulator z jakim pracowa³em. FET do MSP430 fajny ale IAR do d..., za emulator NECa nie chcia³em siê zabieraæ.

pozdrawiam

...

W zasadzie siê z Tob± zgadzam, ale s± te¿ inne rzeczy bardzo u¿yteczne, których MPLAB nie potrafi. Np w zasadzie trzema mieæ 5.7 i 6.x ¿eby da³o siê rozs±dnie pracowaæ z ró¿nymi procesorami. Chyba ¿adna wersja Mplab nie obs³uguje wszystkich dostêpnych procesorów firmy! Microchip jeszcze nie dawno sprzedawa³ ICD1 po czym wprowadzi³a ¶rodowisko 6.x które tego urz±dzenia nie obs³uguje. Procesory 16F87x doczeka³y siê nowszych wersji z literk± A, których te¿ w zasadzie nie da siê zaprogramowaæ a ju¿ na pewno nie debugowaæ przez ICD1.

Dzia³amie Microchipa przypomina politykê Microsoftu - wypu¶ciæ byle co, byle przed konkurencj±. A programista ma schody:( W koñcu zarabiaj± na tych scalakach i mogli by zrobiæ ¶rodowisko raz a dobrze. Kolorowy edytor jest standardem od wielu lat, a w wersji 6.x nadal nie mo¿na zmieniaæ kolorów ani czcionki. W efekcie jest tak beznadziejny, ¿e wolê czarno-bia³y pod 5.7.

Pozdrawiam,

Andrzej Grodecki

sieczkê odczyta jak ma uszkodony programator - odczytywacz

Zablokowany PIC zwraca same 000H !!!

pzdr

AKel

*Ka¿dy* PIC zachowuje siê pod tym wzglêdem identycznie? Mój 16C54 nie zwróci³ samych 00, wiêc nie jest zabezpieczony?

s³owo jest 12 bitowe - wiêc zapisane na 2 bajtach czyli niezaprogramowany PIC OTP - jednokrotnie programowany bo do takich nale¿y PIC16C54 da³ by w odczycie s³owa 0FFFh zabezpieczony przed odczytem poda 0000h

g³owy nie dam ale testowa³em kilka piców z flashem i okienkowych ale to chyba nie ma znaczenia

nie koniecznie - zalezy czy masz dobrze dzia³ajacy programator - i kontakt ptokgramator PIC

je¿³ei co¶ nie styka to mo¿e zwracac smieci - czyli losowe warto¶ci. DObrym testem bêdzie w pliku HEX znale¼æ co drugi m³odszy pó³bajt=0 wtedy sa szanse ¿e odczytane warto¶ci nie s± przypadkowe, a sa po prostu kodem ¼ród³owym. Nie sadze jednak by autor urz±dzenia nie zabezpieczy³ procesora.

pzdr

AKel

>

Te z sieci to by³y raczej klony ICD a konkretnie ICD1. Moim zdaniem raczej nie warto siê w to pchaæ (dok³adnie jak to podsumowa³ Kolega A. Grodecki) Ju¿ lepiej ICD2 bo przynajmniej seriê 18F obs³uguje i chyba w tym kierunku Microchip steruje (dopóki nie przejd± na JTAG to wtedy ICD2 tak¿e do kosza). Ogólnie ICD maj± do¶æ ograniczone mo¿liwo¶ci.

Bo teraz kto szybciej pu¶ci co¶ na rynek ten jest lepszy. Ale jaka firma nie robi takich numerów? A s³ynna maksyma CCC (cena czyni cuda) i kolejne, a¿ do dna bólu (a gdzie to dno?) erraty Atmela. Albo TI - zrobi³em zegarek (chodzi w trybie u¶pienia) i wysz³o ¿e siê spó¼nia przy silnych zak³óceniach EMC (spó¼nia ale nie resetuje!). Zwroci³em siê do TI i dosta³em odpowied¼, ¿e zajm± siê problemem jak bêdziemy brali rocznie powy¿ej bagatela.... miliona(!) sztuk.

A wracaj±c tematu nie s±dzê ¿eby Microchip pu¶ci³ ICE'a za pare tys dolców do samodzielnego monta¿u. Jeden modu³ rozszerzaj±cy kosztowa³ co¶ ko³o $500 jak pamiêtam ceny.

TI FETMSP430 (Flash Emulation Tool) jest do¶æ prosty i tani (jakie¶ $100

- no ale co to jest za wielk± wod±) Jego najwiêksz± zalet± jest kontrola pod JTAG, która nie z¿era zasobów procesora jak ICD. Wad± tylko jedna pu³apka w RealTime (jak ICD ale co wiêcej chcieæ za $100). A rasowy wyjadacz znajdzie w necie schemat gdzie takiego klona FETa mo¿na zrobiæ za góra jakie¶ $20 :) czym trochê os³abi imperialistyczn± gospodarkê ;>

Oprogramowanie (IAR - tragedia ale za free) jest do wziêcia ze strony Texasa lub znajduje sie w oryginalnym zestawie FET ze wszystkimi kabelkami i p³ytk± emulacyjn±.

Pozdrawiam jmdsh

Popatrz co znalaz³em w poni¿szym dokumencie: "PIC16C54 R PIC16C54C Migration"

formatting link
"Code protection change, PIC16C54C now reads as 0 when code protect enabled"

Wniosek z tego p³ynie taki, ¿e PIC16C54 odczytywa³ siê inaczej ni¿ zerami gdy by³ zabezpieczony... Rzuca to "snop ciemnego ¶wiat³a" na t± sprawê... Dochodzê do wniosku, ¿e procek jest niestety zabezpieczony - no trudno.

Prawda jak zwykle leży pośrodku, większość procesorów faktycznie zwraca 0's ale są też takie (starsze serii C), które dają przy odczycie krzaki. Sprawdzone - przetestowane!

pozdrawiam, sword

Czy te "krzaki" s± zawsze takie same czy zupe³nie przypadkowe przy ka¿dym odczycie? Bo ja mam w³a¶nie do czytnienia ze star± seri± C ale "krzaki" odczytujê zawsze identyczne...

W katalogu Microchipa podaj± ¿e niestety dane s± szyfrowane . Wiêc jednak "sieczka" ;(

W którym miejscu to konkretnie wyczyta³e¶?

U¿ytkownik "Pszemol" snipped-for-privacy@PolBox.com napisa³ w wiadomo¶ci news: snipped-for-privacy@poczta.onet.pl...

Dokument 30190h (pdf) strona 7. (Rozdzia³ pt. Code Protection). Dla u³atwienia dodam ¿e jest to specyfikacja programowania dla procków serii PIC16C5xxx.

"In code protected parts, the contents of the program memory cannot be read out in a way that the program code can be reconstructed. A location when read out will read as: 0000 0000 xxxx where xxxx is the XOR of the three nibbles."

¦licznie... dok³adnie to w³a¶nie obserwujê. A wiêc to nie ja robi³em co¶ ¼le - po prostu kostka zabezpieczona. Dziêkujê za informacjê.

ja też odczytywałem identyczne, ale głowy nie dam czy to jest zasada :)

sword

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required