Hauptseite Castellano  Deutsch  English 

Wenn der PIC nicht "mit-arbeitet" ...

Einen PIC zu benutzen ist einfach: man schreibt ein bißchen Code, brennt ihn in den Flash-ROM, setzt den PIC in die Anwenderschaltung, legt Spannung an, und er funktioniert — meistens jedenfalls...

Für alle Anhänger von Murphys Gesetz folgen ein paar Tips, was alles schief gehen könnte.

Der PIC funktioniert überhaupt nicht

Mögliche Ursachen:

  1. Der PIC steckt nicht richtig in der Fassung.
    Das klingt vielleicht blöd, aber es ist nicht unmöglich, ein PIC verkehrt herum einzusetzen, ein Anschlußbein zu verbiegen, oder eine Fassung zu erwischen, die nicht richtig Kontakt gibt.
  2. Fehlende Betriebsspannung.
  3. Oszillator-Ausfall.
    Mein Favorit. Wenn Geschwindigkeit und Genauigkeit keine Rolle spielen, würde ich die Verwendung des internen Oszillators empfehlen. Das vereinfacht das Leiterplattenlayout und gibt zwei zusätzliche Anschlüsse.
  4. Der PIC bleibt im RESET-Zustand.
    Neben der simplen Ursache, daß der /MCLR-Anschluß "versehentlich" auf "Low" gezogen wird, gibt es noch andere, nicht so leicht erkennbare Situationen, die einen PIC vom Laufen abhalten:
  5. Der Debugger ist aktiviert.
    Wenn die Debugger-Logik aktiviert ist, dann führt der PIC die erste Anweisung aus und hält dann an. Deshalb muß man den PIC nach dem Debuggen der Software erneut im normalen Modus programmieren, bevor man ihn in der Anwenderschaltung nutzt.
  6. Der PIC scheint tot zu sein.
    Nach meiner Erfahrung sind PIC nicht so einfach kaputt zu bekommen. Selbst nach einem Verpolen der Betriebsspannung besteht noch Hoffnung. Bevor man ihn zu einer hübschen Skulptur umarbeitet, kann man versuchen, den PIC durch mehrfaches Löschen wiederzubeleben.

Der PIC funktioniert nicht wie erwartet

Mögliche Ursachen:

  1. Falsche Register-Bank ausgewählt.
    Der Maschinencode der PIC 12Fxxx/16Fxxx kann nur die unteren 7 Bits der Registeradresse aufnehmen. Um mehr als 128 Register zu ermöglichen, sind sie in zwei bzw. vier Bänken organisiert. Wenn man Assemblercode schreibt, muß man folglich bei jedem Register-Zugriff darauf achten, daß auch die entsprechende Register-Bank im STATUS-Register ausgewählt ist.
    Falls MASM ein "List file" erzeugt, kann der Editor von 'PicProm' sowohl die HEX-Datei als auch die zugehörigen Quelltextzeilen darstellen, was eine visuelle Überprüfung des erzeugten Codes ermöglicht.
    [Editor]
    (Mit MASM kann man zwar vor jedem Registerzugriff den Pseudo-Befehl "banksel" verwenden, der die nötigen Befehle erzeugt, um die Bank-Bits richtig zu setzen, jedoch würde ich diese Methode aus zwei Gründen nicht empfehlen: erstens läßt sich anscheinend keine Sprungmarke in der gleichen Zeile setzen, und zweitens generiert diese Pseudo-Anweisung immer Maschinencode — selbst dann, wenn die Bank-Bits schon richtig eingestellt sind. Das bläht die Programmgröße unnütz auf und kostet wertvolle Ausführungszeit.)
  2. Falsche Speicher-Seite ausgewählt.
    Der Maschinencode der PIC 12Fxxx/16Fxxx kann nur die unteren 11 Bits einer Programmspeicher-Adresse aufnehmen, wodurch sich ein direkt adressierbarer Bereich von 2 KWords ergibt. Falls die Programmgröße diese 2 KWords übersteigt, muß man vor jedem "goto"- oder "call"-Befehl sicher stellen, daß die entsprechende Speicherseite im Register PCLATH eingestellt ist.
  3. Der Watchdog-Timer setzt den PIC immer wieder zurück.
    Bei eingeschaltetem Watchdog-Timer — was der Default-Zustand ist — muß man "clrwdt"-Befehle so innerhalb des Quelltextes verteilen, daß bei normaler Programmausführung wenigstens alle 10 ms einer von ihnen abgearbeitet wird.
    Bevor man den Watchdog-Timer im Konfigurationswort deaktiviert, sollte man sich klar machen, daß er die einzige Möglichkeit darstellt, mit der ein PIC "sich selbst" befreien kann, falls er durch eine Software-Fehlfunktion in einer Endlos-Schleife "hängt".
  4. Die PORTs wurden nicht richtig initialisiert.
    Nach dem Power-on-Reset können manche PORT-Anschlüsse als Analogeingänge konfiguriert sein, und sie liefern beim Lesen immer '0'. Das ist vom Controllertyp abhängig. Hier hilft ein Blick ins Datenblatt für die richtige PORT-Initialisierung.
  5. Befehl mit einem PORT als Ziel.
    Wenn man die Daten eines PORTs modifiziert, dann ist zu beachten, daß der Befehl den aktuellen – externen – Zustand aller Anschlüsse liest und das Ergebnis in alle Ausgangspuffer des PORTs schreibt. Dies kann zu unerwarteten Ergebnissen führen. Einige Beispiele:
  6. Fehlende Hauptschleife.
    Einfach gesagt: einmal eingeschalten arbeitet der PIC die Befehle im Programmspeicher ab, bis er wieder ausgeschalten wird. Es gibt keinen "Halt"-Befehl, und die "END"-Anweisung am Ende eines Assemblercode-Blockes hat keine Bedeutung bezüglich der Programmabarbeitung.
    Folglich muß das Programmm eine (nie endende) Hauptschleife enthalten oder — falls das Programm nur einmal nach dem Einschalten laufen soll — wenigstens mit einem "goto $"-Befehl enden, um die Abarbeitung von leerem Programmspeicher zu verhindern.
  7. Stack-Überlauf.
    Die PIC 12Fxxx/16Fxxx haben nur 8 Stackniveaus für "call"-Befehle und die Interrupt-Routine. Falls das Programm einen zu starken Gebrauch von verschachtelten Unterprogrammen macht, dann kann ein Stacküberlauf auftreten — und für diesen Fall ist keine Behandlung vorgesehen. Das Programm stürzt einfach ab.
    Aus diesem Grund analysiert 'PicProm' jede HEX-Datei beim Laden und bringt eine Warnung, falls ein Stacküberlauf bei der Programmausführung auftreten könnte.
  8. Fehlender Abblock-Kondensator.
    Ein Abblock-Kondensator von 100nF sollte so dicht wie möglich an die Vdd- und Vss-Anschlüsse angebracht werden. Meine bevorzugte Methode für PDIP-Gehäuse besteht darin, einen kleinen SMD-Kondensator direkt zwischen die Anschlüsse zu löten.

zurück zur Hauptseite