Probleme beim Start des PIC 16F884

[HF SHOOTER]

Hi,

ich habe noch zwei Vorschläge (einmal Hardwarelösung, einmal Softwarelösung):

1. den Reset verzögert auf High legen nachdem die Betriebsspannung zugeschaltet wurde. Z.B. indem man an MCLR einen Kondensator langsam mit einem Widerstand läd, ab einer bestimmten Spannungsschwelle erkennt der PIC am MCLR ein High, und startet dann das Programm.
Optimal wäre natürlich noch ein Schmitttrigger zwischen MCLR und Kondensator zu schalten, um an MCLR entweder 0V oder 5V zu haben und nicht die Ladekurve.

2. Im Initialisierungsteil, also ganz oben - noch bevor die PORTS auf Ein- bzw. Ausgange gestellt werden - eine Warteschleife programmieren von z.B. ca. 0,5s. Entwerde tausendmal nop, nop, ... oder mittels decfsz, goto und ein paar hilfsvariablen.

Viel Erfolg.

mfg
Benny

[phaidros]

Versuche einmal, in der Initialisierungsroutine zu erkennen, welche Art Reset erfolgt ist. POR (Power On Reset), BOR (Brown Out Reset) und WDT Reset lassen sich m.W. unterscheiden.

Falls ein unerwarteter Reset ausgelöst wurde, gleich Programm stoppen und irgendwie an den User melden (LED Pin setzen).
Manchmal kommt man so auf Fehlerquellen.

Als Workaround, falls du den Fehler gar nicht findest, folgender Vorschlag:

Den Watchdog Timer in der Config einschalten.
Das Rücksetzen des WDT so im Programm verstecken, dass es nicht zufällig ausgelöst werden kann, z.B. bestimmte Variablen müssen in bestimmter Reihenfolge mit bestimmten Werten gesetzt werden, erst dann erfolgt ein Zurücksetzen des WDT.
Ziel der Übung ist es, nach dem PowerOn einen WDT-Reset zu erzeugen.
Dann hast du einen definierten Zustand und kannst ab jetzt normal mit deinem Programm fortfahren. (WDT dann abschalten.)

[phaidros]

Ich antworte mal auf meinen eigenen Post, was man ja eigentlich nicht tun sollte.
Aber diese Art Fehler kann einen verrückt machen. Und meine "Lösung" von oben ist doch irgendwie unbefriedigend, weil man dann immer noch nicht weiß, was den Fehler ausgelöst hat.
Nach meiner Erfahrung kann ich eigentlich nur sagen, die PICs sind schon ziemlich deterministisch, also scheinbar zufälliges Verhalten lässt fast immer auf einen Fehler beim Anwender schließen ( minus Errata Sheets).

Deshalb noch ein Vorschlag, um den Fehler weiter einzugrenzen:
Baue doch sukzessive an verschiedenen Stellen deines Programms Endlosschleifen ein. So kannst du ermitteln, ob der PIC wirklich zufällig irgendwo hinspringt oder aber doch immer an dieselbe Stelle, nur eben nicht 0x00.

Viel Erfolg. Wir leiden mit dir.

[Siro]

Aufgrund ähnlicher Erfahrungen mit den Anlaufproblemen
bei verschiedenen PICs, möchte ich hier mal einige
Anregungen loswerden. Vielleicht kommt der eine
oder andere ja dadurch auf neue Ideen für die Anlaufprobleme
bzw. deren Beseitigung.

Ich habe gerade ein ähnliches Problem mit dem PIC 24H.
Nach einer Neuprogrammierung "spinnt" zunächst meine Software,
prinzipell funktioniert sie aber. Es wurde aber genauso wie bei Dir mein
Initialisierungscode irgendwie übersprungen.
Dann bediene ich den Reset Pin per Hand und die Software
läuft einwandfrei. Und das trotz richtiger Reset Beschaltung
mittels RC Glied plus Entladediode für den Resetkondi.
Hab mir mein Reset Signal mit dem Ossi angesehen, es gibt eigentlich
keinen Grund für diese Fehlverhalten.

Dazu möchte ich gleich noch auf ein Problem, welches ich beim 18F4620
festgestellt habe hinweisen. Hier habe ich den Resetpin, genauso wie Du,
als Eingang benutzt. Der Pic tätigt also nur den eigenen internen Reset
von ca. 72ms. Normalerweise dürfte der PIC nun niemals auf den Reset
Pin reagieren. Ich habe es jedoch trotzdem geschafft, mittels Antippen des Resetpins
einen Neustart zu verursachen. Nach diversen Versuchen konnte ich feststellen:
Liegt am Resetpin, obwohl er nur als Eingang programmiert wurde,
z.B durch Störungen (ESD)eine Spannung höher als die Versorgungsspannung an,
führt der PIC einen Reset aus. Hier scheint die interne Resetschaltung
lediglich über eine Diode öder ähnliches abgeblockt zu werden.
Damit könnte man den Pin im Prinzip doppelt belegen, als Eingang
und als Reset mit einer etwas höheren Spannung. Das war jedoch nicht
mein Anliegen, aber trotzdem interressant, mal abgesehen davon,
daß dies ausserhalb der Spezifikationen liegt.

Doch nun zum eigentlichen, eventuellen Problem:
Bei der ICSP Programmierung wird zunächst VPP angelegt,
dann MCLR auf Programmierspannung gelegt. Sind hierbei die
Leitungen RB6 und RB7 (Data und Clock) auf Low geht der PIC
in den Programmiermodus. Dies entspricht eigentlich meinem
normalen Einschaltverhalten. Der MCLR wird über das RC Glied
vorerst auf Masse gehalten und kommt erst eine gewisse Zeit
später hoch. Da beim PIC24 die Programmierspannung identisch
zur Versorgungsspannung ist (3,3 Volt) fragt man sich, wie das wohl
gut gehen kann. Im Low Voltage Programmiermodus der 18er PICs
wird ebenfalls mit der Versorgungsspannung programmiert.
Mal davon abgesehen, daß im Configurationsregister das LVP Bit
gesetzt sein muß.

Meine Vermutung ist, daß beim Einschalten der PIC nicht genau weis,
ob er im Programmiermodus oder im normalen Modus arbeiten soll.
Dies ist aber lediglich eine nicht bestätigte Vermutung.
Wenn nun hierbei auf der Clock Leitung noch irgenwas rumschrappelt
könnte der Programmcounter beim Einschalten falsch stehen und der
PIC springt in die Wüste.
Ein Versuch wäre es noch Wert, die PGD und PGC Leitung mittels
Pullup auf High zu legen. Der PIC hat zwar interne Pullups, die sind jedoch
vorerst nicht aktiviert. Das heist, die Pins stehen auf Input und müssten demnach
beim Einschalten floaten. Sind beide pins High, darf der PIC nicht in den
Programmiermodus gehen.
Zudem könnte man sinnvollerweise eine Shottky Diode vom Resetpin
nach Vdd schalten, damit niemals eine Spannung höher Vdd durch Störungen
in den PIN gelangen kann. Das Problem ist nur, daß diese Verbindung
beim Programmieren geöffnet werden muss, damit die Programmierspannung nicht
über die Diode begrenzt wird.

Da fällt mir noch ein, daß ich mal erhebliche Probleme hatte, weil
mein Abblockkondensator etwas zuweit von den Versorgungspins vom PIC18 war.
Dies führte sporadisch, je nach Programmcode, zu unerklärlichen Ergebnissen.
Die Software lief erst nicht richtig, nachdem ich 2 NOPs irgendwo reinschrieb
lief sie plötzlich. Dies unerklärliche Problem wurde mit Microchip
diskutiert und man erklärte mir, daß der Flash Speicher des PICs in
einzelnen Planes aufgeteilt ist. Durch meine NOPs verschiebt sich der
Code im Flash. Beim Umschalten bzw. aktivieren der Flashbereiche (Planes)
zieht der PIC mehr Strom und kann bei schlechter Abblockung "abstürzen".
Ein kleiner 100nF direkt an den Versorgungspins des PICs löste das Problem sofort.

Übrigens eine Auswerte Routine, wer den Reset auslöste, hatte ich auch in
meiner Software, nur wurde diese beim Start nicht richtig angesprungen.
Damit war die Auswertung nutzlos.

Ich werde auch weiterhin an diesem Problem dran bleiben und
Erfahrungen bereit stellen.

sorry, der Artikel ist doch länger geworden als ich dachte,

mfg Siro

[marcemich]

Hi, Leute! Erstmal vielen Dank für eure ganzen Posts!

Sind echt viele gute Anregungen dabei. Allerdings konnte ich das eigentliche Problem noch nicht beheben. ich habe es jetzt vorerst mit der methode mit dem WDT gelöst. Der Fehler ist bisher nicht mehr aufgetreten, bzw. er wurde durch den WDT-reset sofort unterdrückt.
trotz dem traue ich der Sache noch nicht 100%ig, weil der WDT im Config-word gesetzt wurde und somit nicht mehr zur programmlaufzeit ausgeschaltet werden kann. aus diesem grund läuft der WDT nun ständig und muss jetzt - logischerweise - auch an vielen Stellen im Prg. zurückgesetzt werden.

zwar ist es jetzt bei ca. 500 mal einschalten nicht mehr zu einem undefinierten Zustand gekommen, allerdings wäre es auch möglich, dass der pic beim einschalten fälschlicherweise in eine schleife sprignt, in der der WDT immer wieder zurück gesetzt wird und somit der fehlerhafte start nicht erkannt wird und kein reset erfolgt.

mal abwarten, wie sich der pic weiterhin verhält, und ob der fehler nochmal auftritt...

Meine Empfehlung an dieser Stelle: leiber einen groesseren Pic, mit mehr IOs verwenden und einen ordentlichen hardware MCLR realisieren, anstatt den pic IO-mässig voll auszureitzen.

Ich halte euch auf dem laufenden, was diesen Fehler angeht, und falls ich eine "echte" Lösung für dieses Problem gefunden habe.

Vielen Dank, nochmal für eure Hilfe!