PIC12F675 verliert Programm

[Günter N. (turtle64)]

Hallo,

ich habe hier 12 Stück PIC12F675 liegen. Ein Programm liest 3 Eingänge 
und schaltet davon abhängig 3 Ausgänge, an denen LEDs hängen. Alles 
funktioniert prima, Pullups sind gesetzt usw.
Bei einer bestimmten Eingangskonfiguration wird an einem Ausgang ein 
Rechtecksignal erzeugt, ganz simpel mit einer Verzögerungsschleife.

Nun zum Problem:
Nach dem Programmieren (PICKIT3) funktionieren alle ICs wie gewünscht. 
Eine Stunde später habe ich sie nochmal getestet, jetzt lieferten 5 von 
den 12 nicht mehr das Rechtecksignal.
Neuprogrammieren hilft nicht wirklich. Zuerst funktioniert es, nach 
einiger Zeit nicht mehr.

Kann es sein, dass der Programmspeicher irgendwie Daten verliert? 
Auslesen kann ich die Chips nicht, da Leseschutz gesetzt ist.

[Max H. (hartl192)]

Günter N. schrieb:
> Auslesen kann ich die Chips nicht, da Leseschutz gesetzt ist.
Du könntest sie ja mal ohne Leseschutz flashen.

[Klaus (Gast)]

Günter N. schrieb:
> Zuerst funktioniert es, nach einiger Zeit nicht mehr.

Reset-Leitung offen?

MfG Klaus

[Sudo (Gast)]

Meine Vermutung ist eher das in dein Programm irgend ein murks ist und 
eine variable überläuft oder in ner schleife hängen bleibt.
Allein das du bei so einem simplen Programm schon den leseschutz setzt( 
oh, Gott jemand mein Programm klauen), sagt mir das du wohl nicht so 
über mäßig viel Erfahrung hast.
In 99,9% ist nicht die Hardware sondern ein eigener Fehler das Problem 
und besonders Anfänger neigen dazu lieber allem die schuld zu geben als 
zu realisieren, das es viel wahrscheinlicher ist das sie daran schuld 
sind.
Also schau dir lieber noch mal deinen sourcecode an und im Zweifel lass 
den Debugger mitlaufen oder irgend welche LEDs blinken um zu schauen wo 
es vielleicht hängt.

[Ulli-B (Gast)]

Sudo schrieb:
> Meine Vermutung ist eher das in dein Programm irgend ein murks ist
> und
> eine variable überläuft oder in ner schleife hängen bleibt.

Die Wahrscheinlichkeit, dass es sich um einen Softwarefehler handelt ist 
99,99 Prozent oder mehr.

mfG
Ulli

[Günter N. (turtle64)]

Problem gefunden, es saß, wie viele hier vermutet haben (und ich selbst 
auch) vor der Tastatur.
Es gab im Programm einen Fall, in dem eine Variable nicht initialisiert 
wurde.

#Sudo: Spekulier mal fröhlich weiter, warum ich den Leseschutz setze. 
Über den intellektuellen Gehalt eines solchen Mini-Progrämmchens kann 
man sich lange streiten. Aber der Microcontroller ist Teil eines 
größeren Gerätes, das als Ganzes geschützt werden soll.

Zum Thema Debugger: Das habe ich für den PIC16F675 gar nicht verstanden. 
Das Teil hat doch nur 8 Pins (2xPower und 6 Port-Pins). Beim 
Programmieren wird das Ding irgendwie in den Programmiermodus versetzt. 
Im Betrieb sind die 6 Port-Pins aber eben Port-Pins. Wie kann man da 
debuggen?

#Klaus: Eine Reset-Leitung gibt es nicht, zu wenige Pins.

Ich arbeite normalerweise mit größeren Microcontrollern mit eigenen 
Debug-Schnittstellen.

[Max H. (hartl192)]

Günter N. schrieb:
> Problem gefunden
Willst du uns verraten was es war?

> Im Betrieb sind die 6 Port-Pins aber eben Port-Pins. Wie kann man da
> debuggen?
Pin 4, 6 und 7 sind beim Debuggen keine IOs, sondern für die 
Kommunikation mit dem Pk3.

[Günter N. (turtle64)]

Gerne. Das Programm soll auf GP2 entweder low oder high oder ein 
100Hz-Signal ausgeben, je nachdem, ob die Variable out_blau_12V 0, 1 
oder 2 ist.
Im Fall 2 soll GP2 umgeschaltet werden, dann läuft eine Warteschleife. 
Hier der Programmauszug:

        if (out_blau_12V == 0)
            GP2 = 1;

        if (out_blau_12V == 1)
            GP2 = 0;

        if (out_blau_12V == 2)
        {
            toggler = ~toggler;

            if (toggler > 0)
                GP2 = 1;
            else
                GP2 = 0;

            //delay loop calibrated to 100Hz
            for (i = 0; i < 328; i++);
        }

Das Ganze steckt natürlich in einer Endlosschleife.

Das Problem war nun, dass die Variable toggler (unsigned char) nicht 
immer initialisiert wurde, je nachdem, wie die Eingangssignale im Moment 
des Einschaltens sind. Steht sie zufällig auf 0xFF (oder 0x00), 
funktioniert die Zeile
    toggler = ~toggler;
wie beabsichtigt und schaltet zwischen 0 und nicht-0 um.
Steht die Variable aber auf einer anderen zufälligen Zahl, wird sie 
nicht 0 und GP2 bleibt auf high stehen.

[Peter D. (peda)]

Günter N. schrieb:
> Das Problem war nun, dass die Variable toggler (unsigned char) nicht
> immer initialisiert wurde

Ein Standard konformer C-Compiler hat die verdammte Pflicht, alle 
globalen und static Variablen mit 0 zu initialisieren.

Solche dirty Hacks habe ich früher auch gerne gemacht.
Heutzutage bevorzuge ich fehlertolerantes Programmieren, auch wenn es 
einige ns länger dauert.

toggler = !toggler;

[Sudo (Gast)]

Ich sag ja nix gegen schützen, aber zu sagen ich kanns nicht auslesen 
weil es geschützt ist, ist doch lächerlich.

PS: warum machst du das nicht mit dem timer? Wenn du nur eine Zeile code 
änders kanst du wieder von vorne Anfängen mit deinen 100 Hz