Probleme beim Start des PIC 16F884

Hallo, Leute!

Ich bin ganz neu in diesem Forum und möchte mich deshalb kurz vorstellen:

Also, ich heisse Marc, bin 26, Studiere derzeit Automatisierungstechnik an der Hochschule Darmstadt. Davor habe ich eine Ausbildung zum Mechatroniker gemacht. Ich beschäftige mich schon seit langem mit Elektronik und Technik aller Art. Seit etwa 4 Jahren programmiere ich PICs. Bisher ausschliesslich in Assembler.

Zu meinem Problem:

In einem aktuellen Projekt habe ich den 16f884 verbaut. Die software läuft einwandfrei - wenn sie mal läuft.

Wenn die Leiterplatte, auf der der PIC sitzt komplett spannungsfrei ist, (alle kondensatoren komplett entladen) bevor ich die Betriebsspannung anlege, dann kann es vorkommen, dass der PIC bei Anlegen der Betriebsspannung scheinbar völlig verrückt spielt oder aber das PRG startet ganz Normal.

(achso, es handelt sich dabei um einen TIMER, mit Anzeige über 4 7-Segment anzeigen, vier tasten zum zeit einstellen-starten-stoppen,summer, relaisansteuerung.)

Es ist zwar an der Anzeige zu erkennen, dass es sich um das programm handelt ( Dezimalpunkt der LED-Anzeige Blinkt im Sekundentakt)
aber es scheint so, als hätte das programm nicht bei 00HEX gestartet oder so...

Nimmt man die Betriebsspannung kurz weg und schliest sie wieder an, dann läuft das programm wie es soll.

Hat jemand schon mal ein solches Problem gehabt?
Habe auch schon mit Microchip telefoniert, die wussten aber auch nicht so recht weiter.

im voraus schon mal danke, für eure Antworten!!

Marc

Hallo Marc,

hast Du folgendes in der Config aktiviert:
Power-up Timer (PWRT)
Brown-out Reset (BOR)

PWRT lässt das Programme rst Verzögert anlaufen (ich glaube erst 72ms nachdem die Spannung angelegt wurde)
BOR lösst einen Reset aus sobald die Versorgungsspannung einbricht, das z.B. dann wenn du mit einer Strippe deine Versorgungsspannung anklemmst und dabei beim anklemmen kurzzeitig wieder vom Draht wegkommst, der PIC stoppt und dann wenn die Strippe entgültig fest angeklemmt wurde macht er müll. Mit BOR macht er nun einen Reset.

mfg
Benny

Hallo, Benny!

danke erstmal für deine Antwort!

verstehe aber noch nicht genau, was du meinst...

nach jedem unterbrechen und wieder anlegen der betriebsspannung, auch wenn es eine sehr kürze unterbrechung ist, wie z.b. das kontaktprellen beim anklemmen, macht der Pic doch einen Reset?
Wenn nicht, dann läuft er an der stelle wieter, an der er aufgehört hat.
extrem kurzes prellen müsste eigentlich durch den Kondensator zwischen Vdd und Vss abgefangen werden.

ansonsten, wenn ein brown out reset ausgelöst wird, dann wartet der Pic
die zeit des PWRT bevor er wieder losläuft. Wird BOR aktiviert, dann aktiviert sich automatisch der PWRT mit (zumindest beim 16f884).

mir kommt es so vor, als würden die ersten befehle im programm einfach übersprungen werden.... bin momentan echt ratlos!

Hier mal mei config Word , falls es was nützt.

Code:

---

        __CONFIG    _CONFIG1, _DEBUG_OFF & _LVP_OFF & _FCMEN_OFF & _IESO_OFF & _BOR_ON & _CPD_OFF & _CP_ON & _MCLRE_OFF & _PWRTE_ON & _WDT_OFF & _INTOSCIO
        __CONFIG    _CONFIG2, _WRT_OFF & _BOR40V

---

Ich finde, es klingt nach einer nicht initialisierten Variable.
Check das doch mal.

Hi phaidros

danke, für den tipp aber das ist es leider auch nicht. Ich habe schon so einiges probiert aber ich find den Fehler nicht....

Du Hast im Config Register den MCLR Pin ausgeschaltet.
Versuche doch mal testweise den MCLR Pin zu aktivieren und lege ihn über 10 K an +5 Volt.
Dann probiere ob der PIC immer richtig startet.
Und wenn der MCLR kurz an Masse gebracht wird muss er einen
"richtigen" Reset ausführen.

Führst Du nach einem Reset einen kompletten RAM Clear aus ?
Das ist sehr hilfreich, damit Du immer mit gleichem RAM Inhalten
startest. So lassen sich eventuell versteckte Fehler schneller auffinden.

Bei dem PIC18F252 kann es passieren, daß er den Resetvector NICHT
erwischt. Hier hat Microchip vorgeschlagen bei ORG 0 zunächst
2 NOP Befehle einzufügen. Vielleicht hat dein PIC ein ähnliches Problem
ist jedoch nicht im Errata Scheet deines PICs zu finden.
Aber die beiden NOPs schaden in keinem Falle.
mfg. Siro

Hi Siro!

DAs mit dem MCLR Habe ich schon probiert. der pin ist in meiner schaltung eigentlich ein eingang hatte ihn aber probeweise schon auf +5V.
der reset hat einwandferi funktioniert und das programm ist nach jedem reset über den MCLR richtig gestartet.

einen RAM CLEAR führe ich nicht aus. eigentlich werden alle variablen vor deren benutzung mit entsprechendem inhalt gefüllt. werde ich aber auch mal probieren.

Die sache mit den zwei nops hört sich aber sehr interessant an, da mein erster befehl im programm ein goto INIT ist. überspringt er den, dann landet er in der interruptschleife und danach durch das retfie sonstwo im programm....

vielen dank für die tipps, werde ich morgen gleich probieren!

ich gebe dann bericht, wie es ausgegangen ist...

bis dann..

Tja, schade... das hat auch alles nichts gebracht...
das gibts doch nicht! ](*,)

Servus,

hast du das ganze schon mal auf nem anderen PIC probiert? Um einfach mal den Kontroller auszuschließen.

Gruß

Ich habe es schon mit mehreren 16F884 probiert. überall der gleiche effekt.... einen anderen mit eeprom und annähernd gleicher pinbelegung habe ich nicht...

gruss ME

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

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

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.

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

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!