-         
Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 15 von 15

Thema: Probleme beim Start des PIC 16F884

  1. #11
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    20.10.2007
    Ort
    Bayern
    Alter
    33
    Beiträge
    116
    Anzeige

    Praxistest und DIY Projekte
    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
    cooming soon...

  2. #12
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    05.02.2006
    Alter
    57
    Beiträge
    114
    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.)

  3. #13
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    05.02.2006
    Alter
    57
    Beiträge
    114
    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.

  4. #14
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    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

  5. #15
    Neuer Benutzer Öfters hier
    Registriert seit
    12.01.2008
    Ort
    Bensheim
    Alter
    40
    Beiträge
    12
    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!
    *** Theorie und Praxis - Zwei Welten prallen aufeinander... ***

Seite 2 von 2 ErsteErste 12

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •