Kann ein PIC sich selbst löschen?

Das er sich selbst den Programmspeicher verändert oder gar löscht durch 
einen Reset, ist unwahrscheinlich

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

P.s.: Batterie ist voll.

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.

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.

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?!

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?

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.

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?

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.

>
> 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:
> 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)