Hallöchen, für einen Metalldetektor den ich die Tage bauen will, hab ich den Hexcode vorliegen. Leider ist das eine Probierversion bei der die Anzahl der Einschaltvorgänge registriert wird und nach 200mal Einschalten muss man den Controller neu flashen. Das Projekt ist schon etliche Jahre alt und der Autor sitzt / saß irgendwo im mittleren Osten und kann von mir nicht mehr erreicht werden. Hab es schon über ein Jahr sporadisch probiert, laut Foren in den ich recherchiert habe ist der wohl Hopps gegangen. Gut kommt vor dort unten, wer weiß was der noch so gebastlet hat. So jetzt jetzt mein Anliegen: kann man irgendwie die Einschalbegrenzung umgehen? Ich würde sehr ungern alle paar Wochen das ganze Gerät aufmachen um den Controler neu zu beschreiben. Ist es über die MPLab IDE irgendwie möchlich einen Schreibschutz zu setzten damit der Einschaltvorgang einfach nicht vermerkt wird? Es handelt sich um den PIC16F877. Eine andere Möglichkeit kommt mir erstmal nicht in den Sinn. Wäre schön wenn ich das mal zum Abschluss bringen kann, es kommt immer mal wieder hoch auf meiner "to do Liste". Leider hab ich sowas nicht studiert.... Danke vorab
Wer weiss wie das umgesetzt ist, evtl. wird der Zaehler im EEPROM gespeichert. Das sollte man im Disassembly finden. Stell das Projekt oder wenigstens das HEX File doch mal hier rein.
Die Menge der möglichen Befehlssequenzen, um ins Flash oder EEPROM zu schreiben, sind bei diesen Controllern begrenzt. Der entsprechende Code sollte sich also relativ leicht im Hex-File lokalisieren lassen. Wenn der Programmierer schlau war, hat er aber vielleicht noch irgendwelche Sicherungen (Prüfsumme, CRC o.ä.) eingebaut, um ggf. Code-Manipulationen zu erkennen. Kann also auch sein, daß man doch etwas mehr analysieren muß. Aber mehr als 8K Befehle können es ja nicht sein...
Danke für deine Antwort. Ich werde morgen Mal die hexfiles hochladen (eines für 4x20 LCD das andere für 1602 Display) und die Beschaltung direkt um den Controller als Ausschnitt ich denke das hilft.
bernte schrieb: > Danke für deine Antwort. Ich werde morgen Mal die hexfiles hochladen > (eines für 4x20 LCD das andere für 1602 Display) und die Beschaltung > direkt um den Controller als Ausschnitt ich denke das hilft. Was auch helfen kann ist wenn du den Controller einmal frisch programmierst und anschließend mehrmals einschaltest um den dann erneut auszulesen. Allerdings beim Auslesen FLASH und EEProminhalt abspeichern! Der Pic 16F877 hat einen EEPROM als dedizierten Datenspeicher, kann aber auch in seinen eigenen Programmspeicher (Flash) schreiben. Was relativ klar ist, das ist die Tatsache das der PIC irgendwo seinen Zählerstand ablegt. Wenn ein einfaches Neubeschreiben reicht kann man einen externen Datenspeicher in der Schaltung ausschließen. Wenn der Zählerstand beim Abklemmen der Batterie erhalten bleibt (ausprobiert?) kommt auch der Ram nicht in Frage. Somit bleiben nur EEPROM oder FLASH als einzig verbleibende Möglichkeiten übrig. Zwar würde man in einem solchen Fall, insbesondere bei älteren Typen, häufig ändernde Werte im EEPROM ablegen. Da es sich aber laut deiner Aussage um eine DemoFirmware handelt würde ich das ablegen im Flash dennoch nicht ausschließen wollen. (EEPROM wg. Abnutzung Flashzellen, bei älteren Typen ist die Zahl der GARANTIERTEN Schreibzyklen im Flash vor einem MÖGLICHEN Funktionsverlust ja noch nicht so hoch. Bei neueren ist das erheblich besser, da wird oft ja schon auf einen "echten" EEPROM verzichtet und der Flash ist explizit auch für häufige Schreibvorgänge vorgesehen. -Ganz oder zumindest in speziellen Bereichen-) Ich würde vorschlagen den Pic nach 1x, 10x und 15x Einschalten auszulesen und die Hex Files dann zu Vergleichen. Also: Pic Beschreiben, einmal Einschalten, danach Auslesen. Dann weitere 9 x Ein- und Ausschalten, danach erneut Auslesen Anschließend nochmals 5x Ein- und Ausschalten um einen weiteren Zählerstand zum Vergleich zu haben. Falls im Programm weitere Einstellungen möglich sind die beim Ausschalten erhalten bleiben (dinge wie Lautstärke, Helligkeit der LCD Hintergrundbeleuchtung oder was auch immer, kenne die Schaltung nicht) KEINESFALLS irgendwelche Änderungen vornehmen. Immer dieselben Einstellungen belassen. Mit dem Auslesen nach dem ersten Power Zyklus stellt man fest ob ggf. eine Erstinitialisierung des EEPROM Speichers oder eines Bereiches im Flash stattfindet. Mit dem Auslesen nach 10 und 15 Power Zyklen erhält man dann Vergleichswerte um festzustellen welche Speicherzellen sich wie ändern. Vielleicht reicht das schon aus um mittels Byteweisen Vergleich (automatisiert) ein klares Schema zu erkennen. Wenn man weiß wo genau der Zählerstand abgespeichert wird kann das helfen die fragliche Codestelle zum schreiben (und/oder lesen) des Zählerstands schneller aufzufinden und zu editieren. (Z.b. Ersatz des Schreibbefehls durch NOP wenn möglich. Oder Hardcodierter Rückgabewert beim Lesen ) Unter Umständen kann es aber auch einfacher sein in einem freien Bereich des Programmspeichers einen Patch unterzubringen der beispielsweise beim Einschalten des Gerätes den entsprechenden Speicherbereich jedesmal auf einen Zählerstand von '1' oder '10' zurücksetzt. So könnte man wenn nötig auch umfangreichere Dinge unterbringen wie z.b. eine Neuberechnung eines CRC Wertes. Oder das nur Neugeschrieben wird wenn die Speicherstelle einen bestimmten Zählerstand erreicht hat usw. Dazu fügt man am Anfang des Programms an geeigneter Stelle einen Sprung zum Beginn des "Patch-Codes" ein, am Ende des Patches wird dann zu dieser Stelle zurückgesprungen. Wenn man Glück hat beginnt das Programm schon mit einer Sprungsequenz am Resetvector. (Sobald auch nur ein Interrupt zur Anwendung kommt bei dieser µC serie so gut wie zwingend. Ausnahme nur wenn das sofortige Durchlaufen der Interruptroutine unmittelbar nach Start vorgesehen ist) Dann ändert man die Adresse einfach ab und springt am ende der eigenen Programmsequenz an die ursprünglich in der Startsequenz vorgesehene Adresse. Auch wenn es kompliziert klingt, in der Praktischen Ausführung KANN dies manchmal erheblich schneller und unkomplizierter sein als das Identifizieren und Ändern der Relevanten Stellen mitten IM ursprünglichen Programmcode selbst. Liegt ganz dran WIE die Erfassung des Zählerstands im Programm realisiert ist und ob evtl. Fallstricke vorhanden sind. Gerade auch wenn die Erfahrung gering ist. Kommt aber auf den Einzelfall, die Speicheraufteilung und vor allem auf den Platz an. Aber ohne die grundsätzliche Kenntnis der PIC16 ASM Befehle geht es auch hier nicht. Gruß Carsten
:
Bearbeitet durch User
Carsten S. schrieb: > Auch wenn es kompliziert klingt.... Erinnert mich an alte Amiga Zeiten. Da gabs HW-Module die einen da prächtig unterstützten - Natürlich nur zum Debuggen. Ich habe niemals nicht, auch nur irgend etwas Gecrackt, ich schwör! PS: Klingt wesentlich komplizierter, als es letztendlich ist!
noch eine andere Idee, falls das sperren des speicherns nicht möglich ist so könnte man ja wohl irgendwie den Grundwert von 200 ermittlen und betreffenden wert durch die höchst mögliche anzahl ersetzen zb 56tausend einschaltvorgänge oder so ähnlich?
Wenn die Software sich nicht gegen Änderungen schützt, ist es am einfachsten ein wenig Code zu schreiben, dass immer vor der eigentlichen Software ausgeführt wird und das den Zähler z.B. auf 42 setzt. Dadurch fällt der Zähler immer auf den Werten 42 und 43 'rum, was auf jeden Fall kleiner als die 200 ist.
Jedes mal neu schreiben ist ja auch doof - einfach den Block (sofern es ihn gibt) vom Schreiben ins EEPROM ausbauen (was man tun muss, um in das EEPROM zu schreiben ist ein festgelegter Ablauf der im Datenblatt zu finden ist und so charakteristisch ist, dass man ihn leicht aufspueren kann. Den Check kann man ja drin lassen und den Wert einmalig - beim Flashen - ins EEPROM schreiben. Aber erstmal abwarten, bis der Fragesteller sich wieder mit Details meldet.
Brauch er nicht umbedinkt, er müsste nur immer den gleichen wert schreiben, das ist nur 1 befehle um das W reg. im passenden Moment zu überschreiben direkt bevor in das EEPROM/Flash geschrieben wird, dann kann er den Rest so lassen wie es ist, wehre die einfachste Möglichkeit.
anscheinend gibt es ja einige Möglichkeiten, das noch irgendwie hinzubekommen. heute abend gibt es hexcode für alle danke Euch erstmal das ihr Euch dazu geäußert habt, das gibt mir Hoffnung wäre ein schöner Abschluss für die Winter Bastelzeit
Am besten wie oben schon geschrieben wehren einmal das Org. Hex und einmal eins was du nach einigen malen ein und ausschalten wieder ausliest inkl. den EEPROM Dump. Wobei man das sicher auch in ner Emu machen kann für den Pic16f877 gibt es da genug
ok grade nochmal nachgeforscht in mein ordner liegt noch eine ***.asm datei wäre doch besser als als hex code? ;-) hoffe es ist nicht die falsche datei hab mal mit atmel studio reingeschaut, sieht aus wie ein disassembler der aus dem vorherigen hex mit der einschalbegrenzung erzeugt wurde dann hatte ich da schon mal irgendwann was begonnen würde es helfen dann lade ich die mal hoch?
:
Bearbeitet durch User
Poste einfach mal die hex Datei, dann kann ich das mal durchtesten. Keine ausgelesene Datei, nur die Originale!
:
Bearbeitet durch User
so die entsprechnde hex datei anbei danke für die Mühe
Angehängte Dateien:
-
Meldung.JPG
23 KB
Hier das Resultat, "Code Protect"! Da ist leider nix zu machen.
WAS soll codeprotected sein? Das HEX File hat er ja - natuerlich kann man dort auch die Fuseconfig hinterlegen, aber die kann man nun auch einfach ueberschreiben beim flashen...
Angehängte Dateien:
-
pic16f877a.png
52 KB -
pic16f878.png
51 KB
NAja das ist bei ner HEX Datei ehr nebensächlich, CP ist auch nicht wirklich an sondern Invalid, also nen Falscher wert, der passt ehr zum PIC16F877A vielleicht kann sich der TO nochmal dazu melden ob es nicht der A typ ist. Im Anhang mal der vergleich beim PIC16F877 ist nen Fehler beim Ab typ passt es, die ICs sind zwar ziemlich gleich haben aber minimale unterschide also nicht zu 100% Kompatibel
Angehängte Dateien:
-
protect.JPG
19 KB
devzero schrieb: > WAS soll codeprotected sein? Das HEX File hat er ja Was im Hexfile steht, siehe oben.
Also, im Disassembly vom TO gibt es 2 Stellen, wo in das EEPROM geschrieben wird. Das erfolgt durch einen call von h_0fe8 - da wird dann geschrieben, was zu der Zeit in 0x71 steht. In h_06b3 wird der Wert an 0x64 dekrementiert und dann ins EEPROM geschrieben. Also ein Zaehler der runterzaehlt. Womoeglich muss man nur diesen call ausbauen, das muss man aber mal naeher untersuchen.
Werner H. schrieb: > devzero schrieb: >> WAS soll codeprotected sein? Das HEX File hat er ja > > Was im Hexfile steht, siehe oben. Das ist doch nur das Configword, also die Fuses... also voellig egal. Das muss man ja nicht so schreiben.
Ja sehe ich auch so, warst um einiges schneller, an dem Punkt könnte man 0x64 einfach überschreiben, wenn es nirgend gegengeschenkt wird müsste das klappen. Edit: oder einfach die Zeile rausnehmen aber dann müsste im EEPROM schon ein wert stehen.
devzero schrieb: > also die Fuses... also voellig egal. > Das muss man ja nicht so schreiben. Das solltest du dem Programmierer sagen, der hat in der hex nämlich die "schweinerei" eingebaut. > wird der Wert an 0x64 dekrementiert und dann ins EEPROM > geschrieben. Das EEprom ist leer. K. J. schrieb: > passt ehr zum > PIC16F877A Habe 877 und 877A probiert, kommt aufs Gleiche raus.
devzero schrieb: > Also, im Disassembly vom TO gibt es 2 Stellen, wo in das EEPROM > geschrieben wird. > Das erfolgt durch einen call von h_0fe8 - da wird dann geschrieben, was > zu der Zeit in 0x71 steht. > > In h_06b3 wird der Wert an 0x64 dekrementiert und dann ins EEPROM > geschrieben. Also ein Zaehler der runterzaehlt. Womoeglich muss man nur > diesen call ausbauen, das muss man aber mal naeher untersuchen. In h_0689 wird der Wert durch call von h_0e7c ausgelesen, und auf 0 geprueft.
1 | movwf 0x64 ;0690 00e4 |
2 | movf 0x64,f ;0691 08e4 |
3 | btfss status,z |
Wenn der Wert 0 ist wird h_05ff aufgerufen - was auch immer genau da passiert. Wenn dieser Wert UNGLEICH 0 ist, wird wieder dekrementiert und geschrieben. Das ist mit grosser Wahrscheinlichkeit eine moegliche Stelle.
Ok, bei mir ging es nur Fehler frei beim PIC16F877A aber eigentlich sind die bis auf Kleinigkeiten bei ADC kompatibel, hatte mich schon gewundert. ich würde einfach das "decf 0x64, f" entfernen dann bleibt der wert im GPR erhalten und wird nicht verändert, das könnte Funktionieren die näste zwei befehle holen den wert aus dem GPR und verarbeiten ihn weiter.
devzero schrieb: > Also, im Disassembly vom TO gibt es 2 Stellen, wo in das EEPROM > geschrieben wird. Darauf kann man sich nicht verlassen und nach mehrmaligen starten des Controllers bleibt das EEprom leer?
@ devzero das könnte auch für die Erststart Bedingungen sein, über das HEX wird ja nix im EEPROM abgelegt
Werner H. schrieb: > devzero schrieb: >> also die Fuses... also voellig egal. >> Das muss man ja nicht so schreiben. > > Das solltest du dem Programmierer sagen, der hat in der hex nämlich die > "schweinerei" eingebaut. Sorry, aber das ist doch Schwachsinn. Man kann das HEX nicht codeprotecten. Man kann (muss aber auch nicht) das Configword da mit ablegen und da kann man natuerlich auch CP setzen, aber das muss nicht geschrieben werden. Ist ohnehin egal, selbst wenn es gesetzt ist. Das HEX File ist ja nun mal da und muss nicht ausgelesen werden. Aktives CP bedeutet allein, dass man den PIC am Ende nicht mehr auslesen kann. > >> wird der Wert an 0x64 dekrementiert und dann ins EEPROM >> geschrieben. > > Das EEprom ist leer. > > K. J. schrieb: >> passt ehr zum >> PIC16F877A > > Habe 877 und 877A probiert, kommt aufs Gleiche raus. Kann ja sein, dass das EEPROM leer ist. Es gibt im Code ja 2 Stellen wo ins EEPROM geschrieben wird, vielleicht wird an einer Stelle davon initial geschrieben.. muss man sich naeher ansehen - am einfachsten geht es, wenn der Aufbau existiert.
K. J. schrieb: > Ok, bei mir ging es nur Fehler frei beim PIC16F877A Schon beim nur einlesen der Datei: Configuration 1BBA, Code Protect. Also ist da irgendwas im Hexfile.
Werner H. schrieb: > K. J. schrieb: >> Ok, bei mir ging es nur Fehler frei beim PIC16F877A > > Schon beim nur einlesen der Datei: Configuration 1BBA, Code Protect. > Also ist da irgendwas im Hexfile. Ja, wohl CP im Configword. Und nochmal, das aendert genau was? Du hast sogar ein Disassembly vorliegen.
wow danke, Ihr wisst echt worauf es ankommt den Aufbau kann ich demnächst fertig stellen, Layout der Platine hab ich soweit, Ätzen ist schnell erledigt bin bloß die kommende Woche arbeitsmäßig sehr eingespannt aber Eure Äußerungen ermutigen mich da weiter zu machen
Und speziell fuer Werner H. etwas Nachhilfe: http://ww1.microchip.com/downloads/en/DeviceDoc/31027a.pdf KLICK 27.2 Configuration Word Bits Note 2: Microchip recommends that the desired configuration bit states be embedded in to the application source code. This is easily done in the MPASM assembler by the use of the CONFIG directive. See Subsection 27.2.1 “MPASM’s CONFIG Directive.” KLICK Vermutlich steht im Assemblerfile vom Author (wenn es dann in ASM war, die Compiler koennen das aber natuerlich auch) was a la __CONFIG .... & _CP_ON (oder ALL) & ... Siehe Tabelle 27-1 in dem PDF. Dann taucht CP im Configword auf - das kann man einfach so brennen. Oder es eben wieder wegnehmen. Hat aber mit dem Problem vom TO genau gar nichts zu tun. Lesen, wirken lassen und verstehen. Und dann nochmal ernsthaft die Frage: Was hast Du fuer ein Problem mit CP?
devzero schrieb: > Ja, wohl CP im Configword Mit dem Pickit lässt sich ja das Configword normalerweise editieren, geht aber bei diesem Hex nicht. > Du hast sogar ein Disassembly vorliegen. Aus dem ausgelesenen Pic, villeicht schon mal gestartet, einem 877 oder 877a, mit welchem disassembler... dem würde ich nicht so einfach trauen. > Was hast Du fuer ein Problem mit CP? Keins, der TO hat eins und wir suchen eine Lösung die ihm helfen könnte. > das kann man einfach so brennen. Aber nicht mehr korrekt auslesen um den Counter oä nach starten des Programms zu finden.
:
Bearbeitet durch User
Hi, K. J. schrieb: > Ok, bei mir ging es nur Fehler frei beim PIC16F877A aber eigentlich sind > die bis auf Kleinigkeiten bei ADC kompatibel, hatte mich schon > gewundert. > > ich würde einfach das "decf 0x64, f" entfernen dann bleibt der wert > im GPR erhalten und wird nicht verändert, das könnte Funktionieren die > näste zwei befehle holen den wert aus dem GPR und verarbeiten ihn > weiter. Habe ich auch erst gedacht... Die Frage ist nur ob EEPROM Inhalt Initialisiert wird und das mehr als nur den Counter betrifft. Da müsste man sich die andere Stelle Anschauen wo ins EEProm geschrieben wird. Die Stelle mit der eigentlichen Prüfung die devzero weiter oben erwähnt hat habe ich auch "vom Bauchgefühl" als die richtige Gefunden. Nur er war schneller. Ganz sicher ist man aber nur wenn man das Programm komplett zerlegt oder sich die Dumps nach einigen Powerzyklen anschaut. Wenn die Prüfung 0 ergibt wird ja der Goto Befehl übersprungen, es folgen dann noch einige Call Befehle wobei die meisten nur Bankumschaltung usw. sind. An einer Stelle wird aber noch was mit den EEPROM Werten gemacht. Im weiteren Verlauf des Calls von h_05ff wird der EEPROM Wert noch einem XOR Vergleich mit 0xff unterzogen womit ggf, eine leere (nichtinitialisierte) Speicherzelle festgestellt wird. Da müsste man das Programm noch weiter Analysieren. Am ende der langen Reihe, wenn nicht vorher im weiteren Verlauf des Calls von h_05ff herausgesprungen wird, endet das Programm in einer leeren Endlosschleife was ja nichts anderes ist als ein faktischer Programmstopp. ISt halt die Frage ob das Teil des geplanten Programmaufbaus ist und diese Schleife durch Interrupt verlassen wird oder ob es tatsächlich das Einfrieren des Programms bei Zählerstand null ist. Auf Verdacht würde ich jetzt an der Prüfung selbst ansetzen. Das BTFSS entfernen und einfach einen harten Sprung ausprobieren. Im angehängten File habe ich einfach mal BTFSS und das goto von der Position vertauscht. Dadurch wird der Programmcode hinter dem Goto niemals erreciht. Im Ergebnis genau so wie wenn die Prüfung auf "Null" dann "unwahr" ergibt. Wenn ich jetzt das Ding bauen wollte würde ich das so jetzt erst einmal ausprobieren bevor ich das Programm unnötig totanalysiere. Es kann natürlich sein das die Funktion so überhaupt nicht mehr korrekt ist, aber das sieht man ja dann. Arbeitet das Gerät hingegen aber normal, ist die Wahrscheinlichkeit groß das es das auch dauerhaft tun wird. Wenn gleich man da erst nach 200 (bzw. vielleicht auch 256) Powerzyklen sicher sein kann. Gruß Carsten BTW: Alles vorrausgesetzt das das Dissamssemblierte Listing überhaupt korrekt ist. Es sieht soweit ja erst einmal gut aus und bei PIC ist das meist auch unproblematisch. Aber garantiert ist das nicht!
:
Bearbeitet durch User
Werner H. schrieb: > devzero schrieb: >> Ja, wohl CP im Configword > > Mit dem Pickit lässt sich ja das Configword normalerweise editieren, > geht aber bei diesem Hex nicht. Klar kann man die Configfuses im Pic mit dem pickit nur so lange editieren wie die CP fuse NICHT gesetzt ist. Sonst wäre die CP Fuse ja witzlos. Aber hier liegt ja schon das Hex File vor. Und wenn ich das Hex File habe, dann kann ich problemlos die Fuse Settings im File selbst verändern. Das geht mit dem Hex editor direkt oder für Einsteiger in dem ich das Programm mit MPLAB 8.xx einspiele, vor dem Einspielen in MPLAB aber auswähle das die Fuse Settings im Code ignoriert werden sollen und statt dessen im Fuse Menü von MPLAB die CP Einstellungen selbst wählen. DAS ist nun wirklich das allerkleinste Problem. Gruß Carsten
:
Bearbeitet durch User
Ja stimmt, für mich wehre grade nen Schaltplan recht brauchbar vom Gerät, ich simuliere grade mit GPSIM, allerdinks hängt es etwas weil da einige Taster/Schalter fehlen die ich manuell umstellen muss, das ist recht nerfig
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.