Hallo, meine Frage an euch ist, ob sich ein PIC von selbst löschen kann, oder ist es vielmehr so, dass der PIC sich in einem RESET-Zustand befinden kann, damit er aufhört zu arbeiten. Wenn ja, welche Möglichkeiten können bei einem PIC der Serie 18F26J11 in betracht kommen,wenn er plötzlich nicht mehr richtig funktioniert? Die Frage stelle ich deshalb, weil ein Studienkamerad ein eigenes Gerät gebaut hat, welches einen Ein und Ausschalteknopf hat. Beim Betätigen des Einschalteknopfs war es bis jetzt immer so, dass Gerät immer ohne Probleme lief. Sprich, die LED blinkte in einem langsamen Takt. Nun ist es so, dass das Gerät nach dem Einschalten nicht mehr funktioniert. Das heißt, die LED blinkt nach dem Einschalten durchgehend in einem schnellen Takt und leuchtet nach ca 10 Sekunden durchgehend auf. Was könnte das sein, was vermutet ihr ? BZW. Kann eine Sperre darin sein? Wenn ja, welche und wie bekomme ich diese heraus? Ich habe bereits das Gerät mit dem PIC 3 eingelesen. Jedoch habe ich beim Lesen der HEX Datei überall nur "0" an den Adressen (Bitstellen) gefunden. Deswegen habe ich mich gefragt, ob sich der PIC selbst reseten kann und der Code sich auch somit von selbst löscht?! Gruß, Andy
Das er sich selbst den Programmspeicher verändert oder gar löscht durch einen Reset, ist unwahrscheinlich
Hallo Andreas, was ist das für ein Gerät, und macht es noch etwas anderes, als nur eine LED blinken zu lassen? Vielleicht ist die Batterie leer. Kann es sein, dass der Leseschutz des PICs aktiviert wurde, und deshalb nur Nullen gelesen werden? Gruß John
Hallo trf Hallo John, danke erstmal für eure Antworten. Freut mich sehr. > was ist das für ein Gerät, und macht es noch etwas anderes, als nur eine > LED blinken zu lassen? Das Gerät wird an ein RJ12 Kabel (6-Polig) eingespeist und verändert darin das enthaltene Signal. Beispielsweise ist an einer Station A eine Hardware angeschlossen, welches über das RJ12 an Station B angeschlossen ist. Station B ist hierbei ein Display mit einer digitalen Anzeige. In diesem Fall ein Zähler. > Kann es sein, dass der Leseschutz des PICs aktiviert wurde, und deshalb > nur Nullen gelesen werden? Soweit ich weiß ist der Leseschutz aktiviert, ja. Daher meine Frage, kommt man trotzdem an den Code ran. Hab mal gehört, dass man mit Hilfe eines anderes Lesegerätes dies machen könnte. Man müsste allderdings den Chip herauslöten und ihn dan in einen Adapter reinstecken etc. Ich persönlich vermute auch nicht, dass der Code gelöscht ist, sondern eher dass es am Leseschutz liegen könnte. Weiterhin denke ich, dass irgendetwas (Reset oder Timer) das Gerät nicht zum Arbeiten bringt. Gibt es da Möglichkeiten, das Ding zum Laufen zu bringen? Für weitere Tipps bin ich sehr dankbar. Gruß, Andy
Die moderneren PICs können alle das Programm-Flash beschreiben und damit auch löschen. Das ist aber - absichtlich, aus Sicherheitsgründen - eine sehr umständliche Prozedur und kann eigentlich nicht "aus versehen" passieren.
Hallo usuru, kann man diese Prozedur so im PIC einstellen, konfigurieren, bzw. programmieren? Gruß, Andy
Leseschutz: Macht genau das, was der Name sagt. Hat keinen Einfluss auf die Ausführung des Programms. Reset: Kann man nachmessen, z.B. mit einem Oszilloskop. Stromversorgung: Kann man nachmessen, z.B. mit einem Oszilloskop. Taktquelle (z.B. Quarz): Kann man nachmessen, z.B. mit einem Oszilloskop. Wenn der Fehler schon immer da war bzw. unmittelbar nach dem Ändern der Firmware, dann ist es warscheinlich eher ein Softwarefehler. Softwarefehler können ales Möglich auslösen, auch das von Dir beschriebene Fehlerbild. PIC Controller können sich selbst umprogrammieren. Das dies versehentlich geschieht ist aber eher unwarscheinlich.
Trf schrieb: > Das er sich selbst den Programmspeicher verändert oder gar löscht durch > einen Reset, ist unwahrscheinlich Nein. Ist es nicht. Ich arbeite ja noch mit 8051-ern, die einen externen Programmspeicher meist als EPROM haben. Vor vielen Jahren versuchte ich mal, EPROM durch funktionsgleiches EEPROM zu ersetzen. Die Verblüffung war groß, als manchmal in der rauhen Hobby-Umgebung auf einmal nichts mehr ging, das EEPROM öfter mal völlig leer war. In jüngeren Jahren machte man mal eben ein kleines Verpolerchen oder Kurzschlüßchen, mit Strombegrenzung natürlich, das passiert aber auch Studenten im Labor, und dann war der Speicher hinne. UV-löschbares EPROM bekam ich nie gestört, das ist äußerst robust.
Wobei es einen grossen Unterschied gibt zwischen dem externen EEPROM, das Du damals angehängt hast, und dem in den heutigen uC integrierten Flash. Die externen EEPROMs haben gar keinen Schutz vor versehentlichem Schreiben - das Schreiben soll möglichst einfach möglich sein. Das in einem uC eingebaute Flash ist dagegen geschützt. Um den Inhalt des internen Flashs zu schreiben, müssen mehrere Befehle in einer genau definierten Sequenz und vielfach auch innerhalb bestimmter Zeitgrenzen ausgeführt werden. Und wie bitte willst Du auf einem Chip einen Kurzschluss verursachen?
Jaja, das Selbstlöschen. Also ich kenne das von den Silabs 80C51F350. Also wieso nicht auch beim PIC? Beim Silabs tritt das auf wenn die Spannungsversorgung nicht schnell genug steigt. Ich glaube da gibt es sogar ein Errata zu.
Wilhelm Ferkes schrieb: > Ich arbeite ja noch mit 8051-ern, die einen externen Programmspeicher > meist als EPROM haben. Vor vielen Jahren versuchte ich mal, EPROM durch > funktionsgleiches EEPROM zu ersetzen. > > Die Verblüffung war groß, als manchmal in der rauhen Hobby-Umgebung auf > einmal nichts mehr ging, das EEPROM öfter mal völlig leer war. In > jüngeren Jahren machte man mal eben ein kleines Verpolerchen oder > Kurzschlüßchen, mit Strombegrenzung natürlich, das passiert aber auch > Studenten im Labor, und dann war der Speicher hinne. UV-löschbares EPROM > bekam ich nie gestört, das ist äußerst robust. Beim RESET sind die Kontrollleitungen der 8051-Varianten gerne mal im Schreibstatus. Dann wird das EEPROM an der gerade anliegenden Adresse verändert, meist auf 00h gesetzt. Alter bekannter Fehler. Kenne ich seit ca. 1990. Da hatte ich das eingehend untersucht. Vermutlich sind die internen Treiber kapazitiv an den Kernel gekoppelt. Diese Chips haben ja dynamische Logik und Mindestfrequenz. Tja, und wie lange brauch so ein Quarzoszillator zum Starten?? Genau das ist das Problem! BTW: /RD und /WR kann man bei diesem Controller während das Programmablaufs per Software dauerhaft aktivieren. Letztlich ist das ja nur Port3 ;-)
Hallo Leute, danke für eure Antworten nochmal. Soweit ich weiß, lässt sich ein EPROM Chip mittels UV-Licht löschen. Und bei meinem Chip 18F26J11 ist es so, dass es kein sog. Quarzfenster, wodurch sich der Chip löschen lässt, zu sehen ist. Korrigiert mich, wenn ich falsch liege. Soviel Ahnung habe ich selbst noch nicht von PICs, aber ich denke mal, dass mein Chip nicht aus diesem EPROM besteht, sondern eher aus dem Flash. Und wie gesagt, es wurde gewollt so konfiguriert, dass der PIC nach einer bestimmten Zeit (nach bestimmten Takten) erst einmal außer Betrieb gesetzt ist. Das heißt, an dem Chip selbst ist alles ok, auch die Bausteine sind in Ordnung. Wodurch könnte der PIC noch außer Betrieb gesetzt werden? Habe was von Timern gelesen, einem Watchdog-Timer, verschiedene Reset-Möglichkeiten etc. Ich kann nur widergeben, dass, sobald das Gerät unter Spannung (5 V) steht, die LED durchgehend schnell blinkt und nach etwa 10 Sekunden durchgehend aufleuchtet. Heißt das dann nicht, dass wenn schon mal die LED blinkt, der PIC funktioniert, aber vielleicht ein nur ein Reset konfiguriert wurde? Wenn ja, wie kann man diesen Modus abschalten? Geht das auch, wenn ein Leseschutz aktiv ist? Kann man vielleicht an den Eingängen am Chip etwas auslöten, z.B. habe ich gelesen, dass der MCLR Eingang für ein Reset zuständig sein kann?! Gruß, Andy
Zur Ergänzung habe ich folgendes bei www.sprut.de gefunden unter dem Link : http://sprut.de/electronic/pic/config/config.htm#data%20EEPROM ++Anmerkung++ Flash und EEPROM mit Codeprotection lässt sich zwar nicht mehr von außen (via ICSP) auslesen, aber ein im PIC liegendes Programm kann sehr wohl auf geschützten Speicher lesend (nicht aber schreibend) zugreifen. Falls z.B. beim 16F876 nur ein Teil des Programmspeichers geschützt ist, dann ist der untere Teil des Flash (mindestens 0000h-0FFFh) ungeschützt. Hierhin lässt sich nun ein kleines Programm brennen, das den geschützten Bereich ausliest, und via RS232 an einen PC überträgt. (Ausprobiert habe ich das allerdings nicht.) Wenn man schon CP benutzen will, dann sollte man unbedingt auch den unteren Teil des Flash schützen! Weiß jemand, wie man den Code ohne ISCP auslesen könnte?
Hallo, noch eine kurze Ergänzung und somit eine Frage zugleich. Hier habe ich bei www.sprut.de folgendes gefunden: ------------------------------------------------------------------------ ----------------------------- MCLR-Pin (master clear) Jeder PIC hat ein MCLR-Pin. Wird es auf low gezogen (Vss), dann stoppt der PIC seine Arbeit und führt ein Reset durch. Wird dann das Pin wider auf High gezogen (Vdd), dann beginnt der PIC seine Arbeit vom Beginn an. Damit der PIC normal arbeiten kann, muss dieses Pin also auf High liegen. Nur ganz wenige PICs haben an diesem Input-Pin einen internen pull-up-Widerstand (PIC16F88x). Bei diesen PICs kann das Pin einfach unbelegt gelassen werden. Bei allen andern PICs miss das Pin mit Vdd verbunden werden. Dabei ist anstelle einer direkten Verbindung ein Hochziehwiderstand (10..20 kOhm) zu verwenden. Über einen Reset-Taster verbindet das MCLR-Pin mit Vss. Drückt man den Taster kurz, dann startet der PIC neu. Eigentlich ist das MCLR-Pin nur deshalb vorhanden, damit man einen externen Reset-Taster anschließen kann. Braucht man keinen Reset-Taster, dann ist auch das MCLR-Pin überflüssig. Moderne PICs erlauben es deshalb, in der Konfiguration das MCLR-Pin zu einem normalen IO-Port-Pin zu machen. Dadurch steht dann ein zusätzliches IO-Pin zur Verfügung. Der Reset-Puls an MCLR muss wenigstens ein paar Mikrosekunden lang sein (>2..5 us), damit er vom PIC akzeptiert wird. ------------------------------------------------------------------------ ---------------------------- Wie ist das mit dem MCLR-Pin hier genau gemeint, dass man es auf low ziehen muss, damit ein Reset ausgeführt werden kann? Verbindet man einfach die beiden Leitungen miteinander und es ist automatisch auf low oder wie erreicht man das genau? Die Frage stelle ich deswegen weil ich mich Frage, ob das bei meinem PIC vielleicht so eingestellt wurde.
Und ich habe eine weitere Frage ^^ Wie überprüfe ich, ob vielleicht der PC (Program Counter) sich in einem Zustand befindet, der evtl. den Reset auslöst ? Ist das in der Config? Wenn ja, wie gelange ich dahin? Wenn das Ganze sich im Quellcode befindet, dann komme ich wegen Code Protection nicht dran?!
Da dieses Modul ja so geheimnisvoll scheint. Vielleicht hat es einfach eine geplante Obsoleszenz. Sprich bei jedem Start wird z.B. im eeprom ein counter runtergezählt der sicherstellt, das es nur x mal benutzt werden kann. wenn der counter auf null ist, blinkt es anders und macht nichts mehr. wäre z.b. ne chipkarte die man kauft, benutzt werden kann um x mal zu duschen(or whatever) danach nichts mehr macht. dann muß man ne neue kaufen. um Manipulationen zu verhindern wurde die protection aktiviert. wenn die protektion im chip funktioniert, kann man dann nichts anderes machen als den chip evt komplett löschen. mit anderen worten, der chip ist vielleicht gezielt so programmiert worden, das er nach einer bestimmten zeit nicht mehr funktioniert und du versuchst ihn zu hacken. da dein Studienkamerad es gebaut hat, warum fragst du ihn da nicht einfach ob das normales Verhalten ist. Da er den Source hat wird er dir am besten weiterhelfen können.
andy schrieb: > Soweit ich weiß, lässt sich ein EPROM Chip mittels UV-Licht löschen. > Und bei meinem Chip 18F26J11 > ist es so, dass es kein sog. Quarzfenster, wodurch sich der Chip löschen > lässt, zu sehen ist. Ansich sind alle PICs außer die PIC16C mit Flash (die PIC16C mit EPROM). Doch wenn das wirklich ein PIC18F26J11 ist, hoffe ich, dass er nicht an: andy schrieb: > Ich kann nur widergeben, dass, sobald das Gerät unter Spannung (5 V) > steht, liegt. Wenn er an 5V ist, guck dir mal an, was unter "Operating Voltage Range" steht: http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en533681 andy schrieb: > Weiß jemand, wie man den Code ohne ISCP auslesen könnte? Das hast du doch direkt darüber geschrieben!? andy schrieb: > Wie ist das mit dem MCLR-Pin hier genau gemeint, dass man es auf low > ziehen muss, damit ein Reset ausgeführt werden kann? Verbindet man > einfach die beiden Leitungen miteinander und es ist automatisch auf low > oder wie erreicht man das genau? > > Die Frage stelle ich deswegen weil ich mich Frage, ob das bei meinem PIC > vielleicht so eingestellt wurde. Du legst den Resetpin über einen Widerstand auf Vdd. Wenn du jetzt einen Reset machen willst, also das Programm neu starten willst, kannst du den PIN z.B. mit einem Taster auf Masse ziehen. Ein Kurzschluss entsteht durch den Widerstand nicht. Ein Schaltplan wäre auch mal recht interessant, da schleicht sich auch mal was ein. andy schrieb: > Und ich habe eine weitere Frage ^^ Wie überprüfe ich, ob vielleicht der > PC (Program Counter) sich in einem Zustand befindet, der evtl. den > Reset auslöst ? Ist das in der Config? Wenn ja, wie gelange ich dahin? > Wenn das Ganze sich im Quellcode befindet, dann komme ich wegen Code > Protection nicht dran?! Du solltest dich mal mit dem Aufbau von PICs beschäftigen. Der PC ist ein Register, das hochgezählt oder durch call/goto manipuliert wird. Das was darin steht, ist die Adresse im Flash-Speicher, wo der aktuelle Befehl liegt. Ein Befehl wird aus dem Flash gelesen, bearbeitet, PC hochgezählt. Danach von vorne. Somit kommt immer der nächste Befehl. Mit einem GOTO macht man nichts anderes, als den PC auf eine bestimmte Adresse zu setzen. Und mit der Config hat das auch nichts zutun ;) In jedem Datenblatt ist ein Blockschaltbild. Da einfach mal reingucken, Sprut angucken und in beiden lesen, wie was funktioniert.
Andreas schrieb: > meine Frage an euch ist, ob sich ein PIC von selbst löschen kann, oder > ist es vielmehr so, dass der PIC Mir schon passiert. 5 St. PIC16F84 an einem RS485-Bus, USV fuer die SV ausgefallen, da Akku langsam gestorben. Danach waren 2 der PICs nicht mehr ansprechbar. Die Fehlersuche ergab am Ende, dass die Adressen (die sich im Daten-EEPROM befanden) nicht mehr vorhanden waren (bei beiden). Nachdem nur die Adressen wieder neu geschrieben wurden, liefen die PICs wieder. Anmerkung: Die SW der PICs selbst hatte keine Routine fuer das Schreiben des Daten-EEPROMs. Gruss hro
> Mir schon passiert. > 5 St. PIC16F84 an einem RS485-Bus, USV fuer die SV ausgefallen, da Akku > langsam gestorben. > Danach waren 2 der PICs nicht mehr ansprechbar. Die Fehlersuche ergab am > Ende, dass die Adressen (die sich im Daten-EEPROM befanden) nicht mehr > vorhanden waren (bei beiden). > Nachdem nur die Adressen wieder neu geschrieben wurden, liefen die PICs > wieder. > > Anmerkung: Die SW der PICs selbst hatte keine Routine fuer das Schreiben > des Daten-EEPROMs. > > Gruss hro Also, du meinst, es lag daran, dass die Daten im EPROM nicht mehr vorhanden waren, weil der Akku leer war? Habe ich das richtig verstanden? Gruß, Andy
Können die Daten im PIC (Flashspeicher) auch dadurch gelöscht sein, wenn z.B. der Akku des Gerätes völlig entladen ist?
Mich würde eher mal interessieren, ob er an den 5V hängt, dann kann ich dir nämlich sagen, woran es liegt ;) (siehe oben) Ich würde nicht gleich davon ausgehen, dass das Programm weg ist, sondern Hardware oder Softwareseitig ein Fehler ist.
Andy schrieb: > Also, du meinst, es lag daran, dass die Daten im EPROM nicht mehr > vorhanden waren, weil der Akku leer war? Habe ich das richtig > verstanden? > > Gruß, Andy Nein, ich gehe davon aus (ich war nicht dabei), dass durch den Ausfall der USV die Spannungsversorgung fuer das Netzteil instabil wurde, was dann vermutlich weiter dazu fuehrte, dass die Spannungsversorgung fuer den PIC "irgendwas" gemacht hat. Gruss hro
Abdul K. schrieb: > Beim RESET sind die Kontrollleitungen der 8051-Varianten gerne mal im > Schreibstatus. Dann wird das EEPROM an der gerade anliegenden Adresse > verändert, meist auf 00h gesetzt. > Alter bekannter Fehler. Kenne ich seit ca. 1990. Da hatte ich das > eingehend untersucht. > Vermutlich sind die internen Treiber kapazitiv an den Kernel gekoppelt. > Diese Chips haben ja dynamische Logik und Mindestfrequenz. Tja, und wie > lange brauch so ein Quarzoszillator zum Starten?? Genau das ist das > Problem! > > BTW: /RD und /WR kann man bei diesem Controller während das > Programmablaufs per Software dauerhaft aktivieren. Letztlich ist das ja > nur Port3 ;-) Abdul, das mit deinen Untersuchungen und Pinpegeln beim Einschalten, da könnte schon auch was dran sein. Je nach Schaltung. Ich vermute, eher bei sehr langlamem Anstieg der Versorgungsspannung. Ich verwendete z.B. paralleles EEPROM 2816 rein als Codespeicher in der entsprechenden Schaltungsart, EPROM-Ersatz für den 2716. Allerdings mußte ein Adapter dazwischen, weil 2716 und 2816 sich in 3 Pins unterscheiden. Und da ist nur der Pin /PSEN des 8051 mit /OE und evtl. /CE des 2816 verbunden. Aber ich habs gerade nachgelesen: Siemens schreibt im Handbuch für den 80535, daß die Steuerleitungen ALE und /PSEN beim Reset Inputs mit sehr hochohmigem Pullup sind. In der Produktion werden diese beiden Pins für Tests benutzt. Für ein Schreiben ins EEPROM müßte aber dessen WR-Eingang auf Low liegen, und der ist in der Schaltung fest mit VCC verbunden. Ins EEPROM schreiben konnte man im Normalbetrieb also nicht, der sollte nur reiner Codespeicher sein. Was ich meinte, ist eine Verpolung der Versorgungsspannung. Aber so, daß der Stein noch keinen Schaden leidet. Nun ja, und da waren schon mal alle 2048 Bytes auf einmal gelöscht, und ich durfte das Programm mittels EPROMMER neu brennen. Also unzuverlässig, die Sache. Es sei denn, man hat in seinem Gerät wirklich einen Verpolschutz drin. Im Normalbetrieb passierte nie was in der Art. Früher war ich da mit Verpolungen und Überspannungen nicht so achtsam wie heute, das entwickelt sich erst allmählich. Aber gut so, sonst wären mir die Geschehnisse wiederum nicht aufgefallen. Ob das bei integriertem EEPROM oder Flash in einem µC auch passieren kann, weiß ich nicht. Meine ersten beiden Standard-8051 killte ich tatsächlich mit Überspannung, danach nie mehr was. Wenigstens hatte das noch einen positiven Effekt, ich konnte bei dieser Gelegenheit die stark heizenden NMOS-Typen gegen CMOS-Typen tauschen. Und die Verpolungen schadeten nie, weil meine Bastelnetzteile gar nicht leistungsfähig genug waren, vielleicht 500mA. So eine ältere Karte mit mehreren Chips drauf hält durchaus schon mal ein paar hundert mA Falschpolung aus, ohne daß die Bauteile gleich in den roten Bereich kommen. Ich konnte nur nie genau aus machen, warum das EEPROM bei Falschpolung komplett löscht. Das wäre ja eine feine Schnell-Löschmethode. Aber im Datenblatt steht nichts über diese Betriebsart vollständige Falschpolung des gesamten Bausteins, nur die maximale negative Grenzspannung an einem Pin bei Normalbetrieb. Vermutlich werden im Chip Bereiche leitend, die die Speicherzellen betreffen, und im Normalfall sperren. Überdies wird bei Verpolung auch durch den Chip selbst die Spannung auf 2 Diodenspannungen begrenzt. Deshalb entstehen auch bei höheren Strömen nicht so arge Verlustleistungen.
Beim AVR muß man, wenn man den EEPROM oder Bootloader benutzen will, unbedingt das Brownout-Reset enablen! Ansonsten kann es passieren, daß bei Unterspannung Flash oder EEPROM-Bereiche gelöscht werden. Beim PIC wird es wohl ähnlich sein. Peter
Michael Skropski schrieb: > Mich würde eher mal interessieren, ob er an den 5V hängt, dann kann ich > dir nämlich sagen, woran es liegt ;) (siehe oben) > > Ich würde nicht gleich davon ausgehen, dass das Programm weg ist, > sondern Hardware oder Softwareseitig ein Fehler ist. Also muss ich das Ganze erst einmal mit einem Spannungsmesser überprüfen?! Wo lege ich die Spannung an? Vdd? Gruß, Andy
Also, das Problem lag bis jetzt daran, dass ich beim Auslesen zwar eine Hex Datei ausgeben konnte, allerdings waren dort überall "0"-en, was für mich in erster Linie bedeutet, dass der PIC leer ist. Dazu muss ich sagen, dass ich das Ganze über ICSP mit dem PICKIT 2 bzw. PICKIT 3 gemacht habe. Kann es daher sein, dass der Code dennoch drauf ist und man ihn mit einer anderen Methode auslesen kann? Ein Leseschutz ist drauf, komme ich evtl. anders an den Code?
könnte aber auch der watchdog sein, der den pic immer wieder resetet, weil außerhalb was nicht funzt....
Hi >Also, das Problem lag bis jetzt daran, dass ich beim Auslesen zwar eine >Hex Datei ausgeben konnte, >allerdings waren dort überall "0"-en, was für mich in erster Linie >bedeutet, dass der PIC leer ist. Bei AVRs kann man bei gesetzten Leseschutz auch eine Hex-Datei erstellen. Nur steht dann Müll drin. >Ein Leseschutz ist drauf, Und was meinst du, wozu der gut ist? >komme ich evtl. anders an den Code? Vom Programmierer. MfG Spess
Nehmen wir mal an, der Watchdogtimer ist im PIC aktiviert. Was ist jetzt, wenn ein Leseschutz drauf ist und ich dennoch in der Konfiguration den WDT deaktiviere? Überschreibe ich den PIC dann, bzw. löscht sich dann das Programm?
hier liegt der Hund begraben: > Also, das Problem lag bis jetzt daran, dass ich beim Auslesen zwar eine > Hex Datei ausgeben konnte, > allerdings waren dort überall "0"-en, was für mich in erster Linie > bedeutet, dass der PIC leer ist. Dazu muss ich sagen, dass ich das Ganze > über ICSP mit dem PICKIT 2 bzw. PICKIT 3 gemacht habe. Kann es daher > sein, dass der Code dennoch drauf ist und man ihn mit einer anderen > Methode auslesen kann? Ein Leseschutz ist drauf, komme ich evtl. anders > an den Code? Wenn ein PIC einen Leseschutz hat, dann kann man ihn nicht über ICSP auslesen, es werden immer Nullen ausgegeben (kann man einfach ausprobieren), das ist ja der Sinn eines Leseschutzes. Der Code wurde also nicht gelöscht, er kann wegen des Schutzes nur nicht von aussen gelesen werden. Wenn der PIC nicht das tut, was er soll, ist er entweder falsch programmiert oder irgendeine äussere Bedingung ist falsch (Spannung/Brown-out, Watchdog, EMV, Block-C, offene Eingänge, etc). > Nehmen wir mal an, der Watchdogtimer ist im PIC aktiviert. Was ist > jetzt, wenn ein Leseschutz drauf ist und ich dennoch in der > Konfiguration den WDT deaktiviere? Überschreibe ich den PIC dann, bzw. > löscht sich dann das Programm? Nö. Der WDT beeinflusst die Config-Flags nicht. Der WDT macht nur einen Reset, die Config-Flags bleiben, wie sie sind. Die Config-Flags können nur per ICSP-verändert werden.
andy schrieb: > Also, das Problem lag bis jetzt daran, dass ich beim Auslesen zwar eine > Hex Datei ausgeben konnte, > allerdings waren dort überall "0"-en, was für mich in erster Linie > bedeutet, dass der PIC leer ist. Dazu muss ich sagen, dass ich das Ganze > über ICSP mit dem PICKIT 2 bzw. PICKIT 3 gemacht habe. Kann es daher > sein, dass der Code dennoch drauf ist und man ihn mit einer anderen > Methode auslesen kann? Ein Leseschutz ist drauf, komme ich evtl. anders > an den Code? Wenn du "0"en ausliest dann sagt das nix aus ob der PIC leer oder Programmiert ist sondern das die "CodeProtection" gesetzt ist (PICkit User manual S.24) Wenn in CONFIG6H auch noch WRTC gelöscht ist, können auch die CONFIG's via ICSP nicht verändert werden....da bleibt nur die Neuprogrammierung. (zum Beisiel beim 18F2450/55/ etc so)
> > Nö. Der WDT beeinflusst die Config-Flags nicht. Der WDT macht nur einen > Reset, die Config-Flags bleiben, wie sie sind. Die Config-Flags können > nur per ICSP-verändert werden. Danke für die Antworten erstmal. Freut mich sehr. Welche config flags kann man z. B. Ändern, und ist es aus hardware sicht oder software gemeint?
Andy schrieb: > Welche config flags kann man z. B. Ändern, und ist es aus hardware sicht > oder software gemeint? Der Brounout-Detektor scheint mir sinnvoll, wie Peter Dannegger es schon beschrieb.
>Welche config flags kann man z. B. Ändern, und ist es aus hardware sicht >oder software gemeint? Du kannst alle Config Bits ändern. Wenn du die Bits für die Codeprotection änderst wird das Flash gelöscht. Das wird nix mit dem auslesen des PICs und Softwareklau.
Der Brownout hat bei den PICs mit EPROM und/oder Flash nichts zu tun, das mag bei den AVRs anders sein. Brownout ist ja eigentlich nur bei Batterieversorgung interessant. Was uns aber bisher vor allem fehlt, ist der komplette Schaltplan und der komplette Code, den kann er ja von seinem Kollegen bekommen. Erst dann kann man feststellen, wo es klemmt. Alles andere ist "Glaskugel".
Also, nachdem ich den PIC auslese und mir die Configuration anzeigen lasse, dann sieht man, dass der PIC Code Protected ist. Ich habe die Hex Datei exportiert und es sind überall "0", wie bereits erwähnt. Die Größe der Hex Datei ist 180 KB. Gibt es die MÖglichkeit diese Datei umzuwandeln, sodass man den Code wenigstens lesen kann? Gruß, Andy. P.S.: Mittlerweile habe ich den PIC gelöscht. Wenn ich die "code-protected" Hex Datei nun in den PIC importiere, funktioniert leider nix mehr. Kann man da noch was machen?
andy schrieb: > ......Ich habe die Hex Datei > exportiert und es sind überall "0", wie bereits erwähnt. Die Größe der > Hex Datei ist 180 KB. > > Gibt es die MÖglichkeit diese Datei umzuwandeln, sodass man den Code > wenigstens lesen kann? > > Gruß, Andy. > > P.S.: Mittlerweile habe ich den PIC gelöscht. Wenn ich die > "code-protected" Hex Datei nun in den PIC importiere, funktioniert > leider nix mehr. Kann man da noch was machen? Nein - nur eine Software mit hellseherischen Fähigkeiten köntte aus einer Hexdatei voll "0" Code erzeugen bzw welche Sinn hätte eine CP wenn's so einfach wäre. Was du machen kannst? Sourcecode besorgen, Compilieren und neu flashen.
andy schrieb: > Soweit ich weiß, lässt sich ein EPROM Chip mittels UV-Licht löschen. > Und bei meinem Chip 18F26J11 ist es so, dass es kein sog. Quarzfenster, > wodurch sich der Chip löschen lässt, zu sehen ist. > > Korrigiert mich, wenn ich falsch liege. Du liegst falsch. Das fehlende Fenster sagt nichts über die Art des Speichers. Aus Kostengründen gab es von den EPROM-PICs früher zwei Versionen: Die teure mit dem Quarzfenster für die Entwicklung und eine Version mit einem Billiggehäuse ohne Fenster, das sich genauso programmieren ließ, aber nicht wieder löschbar war (OTP-One Time Programmable)
andy schrieb: > P.S.: Mittlerweile habe ich den PIC gelöscht. Wenn ich die > "code-protected" Hex Datei nun in den PIC importiere, funktioniert > leider nix mehr. Das ist doch der Sinn des Ausleseschutzes. Nur ein völliger Ignorant hätte was anderes erwartet. Peter
Hallo Leute, könntet ihr euch mal mit dem Geschwurbel und Herum-Theoretisieren über 8051, EPROM, EEPROM, UV-Fensterle und die guten alten 1990er zurückhalten!? Das bringt doch nichts ... Und den Thread-Starter würde ich mal bitten, in Zukunft die Antworten zu lesen (zur Wirkungsweise der Code-Protection) und seinserseits Fragen zu beantworten, insbesondere die einzig sinnvolle hier: Michael Skropski schrieb: > Doch wenn das wirklich ein PIC18F26J11 ist, hoffe ich, dass er nicht an: > > andy schrieb: >> Ich kann nur widergeben, dass, sobald das Gerät unter Spannung (5 V) >> steht, > > liegt. > > Wenn er an 5V ist, guck dir mal an, was unter "Operating Voltage Range" > steht: > http://www.microchip.com/wwwproducts/Devices.aspx?... Wenn du/dein Kollege also eine Betriebsspannung von 5V an den 18F46J11 legst, dann wäre das eine Erklärung für das Verhalten ... Zitat Datenblatt: "Operating Voltage Range of 2.0V to 3.6V" Zur Erklärung: Die PICs sind schon recht robust, und werden deshalb auch nicht sofort sterben, was dazu passen würde, dass das Gerät ja doch ein Weilchen funktioniert hat. HTH PS: Was heutzutage so alles studiert ... SCNR
Ich frage mich, wo das Problem ist? Es ist doch umständlicher mit einer nicht realisierbaren Software aus einem Haufen Nullen, den Ursprünglichen Code rauszuholen, anstatt einfach die Software von deinem Kumpel/Bekannten zu besorgen. Dann isses auch total egal, ob es Codeprotected ist, wenn du die Source-Hex hast. Genauso gut kannst du dir von ihm den Code in C oder ASM besorgen um darin nach fehlern zu guckenn und du kannst dir von ihm auch den Schaltplan holen, wo meines Erachtens ein Fehler am warscheinlichsten ist. Wenn du das weiterhin ignorierst, wirst du hier nichts als dumme Sprüche ernten. Ohne Schaltplan, Ahnung, Infos und ggf ohne Softwarecode, kann man die Fehlersuche schon fast lassen. Ich kann mir nur 3 Situationen vorstellen. 1. Du ignorierst aus irgendeinem Grund die Dinge mit der Spannung bzw Schaltplan und lässt dir somit garnicht helfen. 2. Du lügst, es ist garnicht von einem Bekannten sondern hast dir eine Geschichte ausgedacht um an die Info zu kommen, ob und wie man einen Codeprotrected- PIC auslesen kann. Da spricht dafür, dass du keinen Schaltplan und Code hast. 3. Du bist nur ein Troll, der bewusst auf nichts hört und Fragen mehrmals hintereinander stellt, die dazwischen schon immer beantwortet wurden um uns zu ärgern. In diesem Fall wirst du warscheinlich bald zurecht beleidigt und abgewiesen.
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.