Hallo in meinem größeren Programm habe ich in ab und zu Programmabstürze (1  mal im Monat). Damit das Programm neu startet, habe ich den Watchdog Timer aktiviert. Das funktioniert ganz gut. Nun meine Frage: Gibt es eine Möglichkeit den Programmcounter zu sichern um eine Fehlerdiagnose zu machen? Ober habt ihr eine andere Idee? Ich habe mir auch schon überlegt den 31-stufigen Stack Speicher zu sichern, bin mir aber nicht sicher ob das mir was bringt.
Mit der Watchdog   Zeit Umrechnung habe ich meine Probleme. Laut Datenblatt (Pic 18F4685, Dokument 39761b) soll ich eine Taktfrequenz von 31KHz haben, was eine Zeit von bis zu 131072s ergibt.

,,For PIC18F2682/2685/4682/4685 devices, the WDT is driven by the INTRC source. When the WDT is enabled, the clock source is also enabled. The nominal WDT period is 4 ms and has the same stability as the INTRC oscillator. The 4 ms period of the WDT is multiplied by a 16-bit postscaler. Any output of the WDT postscaler is selected by a multiplexer, controlled by bits in Configuration Register 2H. Available periods range from 4 ms to 131.072 seconds (2.18 minutes). The WDT and postscaler are cleared when any of the following events occur: a SLEEP or CLRWDT instruction is executed, the IRCF bits (OSCCON<_x0036_:_x0034_>) are changed or a clock failure has occurred. . 24.2.1 CONTROL REGISTER Register 24-14 shows the WDTCON register. This is a readable and writable register which contains a control bit that allows software to override the WDT enable Configuration bit, but only if the Configuration bit has disabled the WDT. FIGURE 24-1: WDT

Dies kann ich leider nicht nachvollziehen. Ich habe einen Vorteiler von 128 und einen programmierbaren Teiler von bis zu 32738 das ergibt bei 31Khz:
128*32768s/31000 = 135176,1s
Wenn ich das Ganze mit 32Khz rechne
128*32768s/32000 = 131072s was im Datenblatt steht.
Was stimmt nun?
Die 31Khz oder die 32Khz
Die 135176s oder die 131072s
Kann Microchip nicht rechnen, oder stimmt das Datenblatt nicht?

muss natürlich ms heißen

ich habe mal ein kleines Testprogramm eingefügt, da wird bis 131 gezählt, was eine errechnete Taktfrequenz von 32Khz entspricht.

        case ausg_watchdog:
            LED_or = LED_OFF;
            stdOut_mr =stdOut;
            stdOut = source_lcd;
            test_wdg=0;
            ClrWdt( );
            while(1){
                if(TimerFlag.IF1s){
                    TimerFlag.IF1s=0;
                    test_wdg++;
                    printOut("%bu\n",test_wdg);
                }
            }
            break;

Hier lese ich aber immer noch 31KHz!
The other clock source is the internal RC oscillator
(INTRC), which provides a nominal 31 kHz output.
INTRC is enabled if it is selected as the device clock
source; it is also enabled automatically when any of the
following are enabled:
• Power-up Timer
• Fail-Safe Clock Monitor
• Watchdog Timer
• Two-Speed Start-up

aber egal, ich bin noch am Überlegen ob ich den "Program-Counter" sichern kann.

Zitat von: pic18 in 07.02.2023, 10:33:26 CETWas stimmt nun? Die 31Khz oder die 32Khz

Das Datenblatt sagt aus meiner Sicht deutlich, dass für die Nutzung des WDT nur ein Oszillator in Frage kommt und der läuft mit "nahezu" 31 kHz.

The other clock source is the internal RC oscillator
(INTRC), which provides a nominal 31 kHz output.
INTRC is enabled if it is selected as the device clock
source; it is also enabled automatically when any of the
following are enabled:
• Power-up Timer
• Fail-Safe Clock Monitor
• Watchdog Timer
• Two-Speed Start-up

Setting this bit selects INTOSC as a
31.25 kHz clock source by enabling the divide-by-256
output of the INTOSC postscaler. Clearing INTSRC
selects INTRC (nominally 31 kHz) as the clock source.

Grüße, picass

es sind aber in der Praxis 32Khz. Das habe ich auch gemessen.
The 4 ms period of the WDT is multiplied by a 16-bit postscaler. Any output of the WDT postscaler is selected by a multiplexer, controlled by bits in Configuration Register 2H. Available periods range from 4 ms to 131.072 seconds (2.18 minutes)

Aber interessanter ist mir die ganzen Register zu retten. Ist da irgendwie möglich?

Register wie PC oder Stackpointer zu retten ist wohl nicht möglich.

Gedankenspiel:
Eine Möglichkeit wäre vielleicht, im Programm an sinnvoll definierten Stellen (Eintritt in eine Funktion) einen  Index zu setzen und diesen in ein Register zu schreiben, welches beim WDT-Reset nicht verändert wird, ein Port sollte wohl gehen, weil er nach dem RESET nicht automatisch zurückgesetzt wird. Der EEPROM ist dazu leider nicht geeignet wegen der begrenzten Schreibzyklen, ein FRAM würde aber funktionieren.
Oder hast Du mal getestet, ob der Inhalt eines Bytes im RAM erhalten bleibt? Schließlich hat es beim Ansprechen des WDT normalerweise keinen Spannungseinbruch gegeben.
Ist dann nach einem RESET das TO-Bit in RCON gelöscht, wurde der WDT aktiviert und man kann den Inhalt dieses Registers abfragen und ggf. speichern, um wenigstens den Ort des "Hängers" zu lokalisieren.
Ob's funktioniert? Wer weiß???

Gruß
PICkel

vor Jahren hatte ich schon einmal ein Programm geschrieben, welches den 31 Stufigen Stack sichert. Irgendwie ist es aber in Vergessenheit geraten. Den Adresspointer von den Unterprogrammen zu sichern hatte ich mir auch schon überlegt. Man könnte die Daten in einen Ringpuffer schreiben und hoffen das die Daten beim Reset nicht gelöscht werden. Im Moment läuft das Programm einige Tage ohne WDT - Reset durch. Kann man den WDT irgendwie auslesen? Dann hätte ich eine Vorwarnung, wenn der Reset kommt.

Bei der letzten Programmänderung hatte ich auch einen Fehler gefunden den ich schon länger gesucht habe. Ich habe ja 2 LCD Anzeigen, diese habe ich so programmiert, das wenn ich in die letzte Spalte schreibe der Anzeigetext um jeweils eine Zeile nach oben scrollt, ich lese die Zeile von der Anzeige aus und schiebe sie um eine Zeile jeweils hoch. Wenn ich das Programm mit dem USB Bootloader aufspielte dann lief das Prog. jedes mal einwandfrei. Bei Stromausfall stimmte der Text plötzlich nicht mehr. Ich hatte immer einen Hardware Fehler gesucht, Lese und Schreibzeiten des Display geändert und nach Pullup Widerstände geschaut. Manchmal war mit der ganzen Messerei auch eine Leitung abgerissen. Dabei lag der Fehler wahrscheinlich an den abgeschalteten USB Baustein welcher auf den selben Datenbus liegt. Diesen hatte ich vor langer Zeit abgeschaltet, da das Programm beim Start auf die USB Schnittstelle wartete. Durch Benutzung des Bootloaders wurde die Schnittstelle initialisiert und das Prog lief anschließend einwandfrei. Bei Stromausfall war der Fehler da. Jetzt habe ich die Leseleitung initialisiert, somit sendet der USB-Baustein keine Daten auf den Bus. Der Fehler ist hoffentlich damit weg. Ich frage mich jetzt was so ein Port an Kurzschlüssen aushält, ob da eine Strombegrenzung ist?

@pic18
Anfangs schriebst du von "Programmabstürzen" und dass der WDT damit zusammenhängen könnte, zuletzt nun von "Stromausfällen" (SA). Letztere sind eine dicke Hausnummer, dazu später.

So richtig deutlich drückst du dich bei deinen Fehlerbeschreibungen nicht aus. Das klingt schon fast so, als ob da zwei voneinander unabhängige Probs vorhanden sind.
Zwei Vorschläge hätte ich, wobei ich eben bemerkt habe, dass PICkel einen davon bereits ausführte: Indexerstellung.
Selbst hatte ich vor Jahren mal in einem längeren Programm (Rollladensteuerung) einen sehr versteckten Fehler aufgespürt, indem ich im Programm eine Variable an reichlich vielen Stellen angebracht hatte, die sich je nach Programm-Position aktualisierte. So konnte die letzte, vom Prog noch "normal" verarbeitete Position erkannt werden, und danach von da aus mit Feintuning die Fehlerstelle eingegrenzt und ermittelt werden. Allerdings gab es keine Probs mit SA's.
Eigentlich müsste man das interne EEPROM schon nutzen können - soweit frei. Du müsstest ja nicht Hunderte oder gar Tausende an Bytes und das auch noch in einer einzigen Speicherstelle sichern. Bei Bedarf lässt sich das ja auch aufsummieren, also hinter einander weg abspeichern.

Vermutest du nur oder bist du sicher, dass es SA's gibt? Falls du unsicher bist, ließe sich das einfach überprüfen, indem externe Hardware dafür an die Uv angeknüpft wird, welche einen Spannungsausfall auch in Form eines kurzen Spikes notieren würde. Eine ebenfalls extra Versorgungsspannung für diese HW wäre auch kein Prob: 3 Batterien würde reichen.
Grüße, picass

Das mit den Systemabstürzen ist schon richtig geschrieben. Die der Fehler bei Neustart nach Spannungsabfall vom letzten Beitrag ist ein anderer. Diesen hatte ich erwähnt um zu zeigen wie verschiedene Fehler zusammen hängen können. Das die Fehler mit dem WDT zusammenhängen habe ich auch nicht geschrieben. Ich habe nur den WDT programmiert um bei Systemabstürzen das System neu hochzufahren, ich schalte dann auch eine LED nach dem Start durch den WDT.
Heute morgen wurde das System mit dem WDT nach über eine Woche neu gestartet. Die LED leuchtete, die alten Daten wurden neu initialisiert. Wo der Fehler zu suchen ist weis ich nicht. Evtl. wird auf irgend einen Eingang gewartet.

Das Wort ,,Systemabsturz" bei µC's halte ich für erklärungsbedürftig. Bei einem PC unter Windows würde das bedeuten, der PC ist mit einem ,,Knacks" raus aus Windows und der PC startet neu, sofern das W-System nicht komplett durch den Wind ist. Bei deinem Prog muss aber wohl anderes passieren, sonst bräuchtest du keinen WDT, um das Prog neu zu starten.
Würde der in einer Schleife festhängen, wie von dir erwähnt, rsp. auf eine Porteingabe warten, oder könnte der ans Ende des Progs gesprungen sein, und wenn der nicht ,,sauber" abgestürzt und entsprechend sauber und korrekt wieder von Neuem gestartet wäre, dann muss sich die Position des Hängers mit der angesprochenen Indizierung, also dem Setzen von nachvollziehbaren Markern erkennen lassen.

Was macht denn das Prog im Simulator? Nicht jeder schätzt den so, aber ich lasse jedes Prog erst mehrfach dadurch laufen. Erst dann, wenn der Simulator einwandfreie Läufe zulässt, lasse ich das Prog auf einen PIC los. Danach gibts ja noch die Möglichkeit, das Prog im PIC zu debuggen. Das dauert – je nach Länge und Komplexität des Progs, aber die Teile, welche in Ordnung sind, müssen ja nur einmal durchlaufen werden - geschicktes Setzen von Stopppunkten hilft sehr. Mit Geduld kann man mit diesem Debuggen so Etliches erreichen, zumal sich ja auch Port-Eingaben simulieren lassen.

Manchmal helfen auch sehr frugale Methoden weiter. Bei meinem jüngsten Prog, dem Maulwuf-Verscheucher – also dem versuchten  - , lief anfangs wenig zusammen. Weil ich da auch drohte, den Überblick zu  verlieren, hatte ich eine der viel geschätzten Platinen des ,,PICkit Low Pin Count Demo" – Boards mit  viel Lametta geschmückt, will sagen, an fast alle Ports LEDs ran gehängt, siehe Bild. Und dann ging es auf einmal schnell. Deren Leuchtmuster entlarvte die Schwachstellen äußerst fix und wo mir beim Starren auf den Bildschirm-Inhalt mit dem Prog der Überblick verloren zu gehen drohte, ergab sich mithilfe der LEDs die Richtung für die Fehlerbeseitigung wie von selbst.

A pro po Spannungs-Einbrüche, da hattest du dich noch nicht zu geäußert. Was geht denn da ab....., taugt das NT nichts, ist das einer Spitzenstrombelastung nicht gewachsen? Oder sitzen da – nur als Beispiel – Relais in der Schaltung, welche keine anti-parallele Dioden an der Spule haben, oder sind die direkt an der 5-Volt-Versorgung des PICs?

Ich hatte auch schon mal einen "winzigen" Steuer-PIC zusätzlich eingesetzt, welcher mit einem Minimal-Prog nichts anderes zu tun hatte, als den unzuverlässigen Kumpel auf der Hauptschaltung zu überwachen, rsp. dessen Fehlverhalten zu markern.
Grüße, picass

das Programm läuft seit dem letzten Start immer noch durch. Der Fehler taucht selten auf, debuggen und im Simulator testen bringt meiner Meinung nichts. Außerdem habe ich auch keinerlei Ports mehr frei.
Leider werden die Variablen nach einen Neustart durch den Watchdog gelöscht, obwohl ich sie nicht initialisiert habe. Ich weis nicht, ob das der C18 Compiler automatisch macht. Ich probiere mal auf einer ganz gewissen Speicherzelle was zu schreiben und schaue, ob der Inhalt noch da ist.

Deine Terminologie lässt es aus meiner Sicht an Klarheit zu wünschen übrig. Was genau verstehst du unter dem Begriff "Absturz eines µC's" ?
Die Analogie zum PC hatte ich ja schon gezogen, nochmal: wenn der, rsp. sein Betriebssystem "abstürzt", dann startet es anschließend von selbst neu. Sollte also dieser Art dein PIC "abstürzen", müsste er ja vom Anfang des Progs an normal wieder laufen. Es wären dann zwar diverse Variable mit ihren aktuellen Werten resettet, aber laufen müsste das. Ist das bei deinem µC so?

Und du sagst weiterhin nichts über die "Spannungs-Einbrüche". Gäbe es die tastsächlich, müsste das natürlich beseitigt werden, rsp. die Ursache gesucht werden.
Grüße, picass

der Pic startet ja nach WDT Auslösung neu. Ich möchte aber gerne die gewisse Parameter erhalten, die Variablen werden alle auf Null gesetzt. Ich denke das macht der C18 Compiler.

Zitat von: pic18 in 16.02.2023, 11:39:52 CETdie Variablen werden alle auf Null gesetzt. Ich denke das macht der C18 Compiler.

Hallo pic18,
Du hast wahrscheinlich recht. Ich habe mal kurz einen Test mit einem 18F24K22 in mikroBASIC gemacht, da bleibt eine Variable im RAM erhalten.
Kurze Beschreibung:
Bei Neustart (Reset, Power_on) blinkt der komplette PortA kurz auf.
Die Testvariable wird auf 0 gesetzt.
Bei WDT-Reset blinkt PortA.0 kurz auf, die Testvariable wird inkrementiert und auf PORTB angezeigt. Es zeigt sich, dass der Wert in der Testvariablen erhalten bleibt.

Gruß
PICkel

program WDT_Variablentest
' getestet mit mikroBASIC V 7.6
' Test des WDT in Bezug auf RAM-Inhalte
' PIC18F24K22 @ 1MHz INTOSC (default)
' WDT ein, Postscaler auf 1:512 (ca. 2sec)

' bei jedem WDT-Reset wird testvar inkrementiert und an PORTB angezeigt,
' bei jedem Aktivwerden des WDT blinkt PORTA.0 kurz auf
' bei RESET erfolgt an PORTA einmalig die Anzeige von 0xFF

' Declarations section 

dim testvar as byte

main:

TRISA = 0
TRISB = 0
LATB = 0
if testbit(RCON,3) = 0 then    ' WDT hat zugeschlagen
  clrwdt
  inc(Testvar)
  LATA = 1
else                           ' normaler RESET
  LATA = 255
  Testvar = 0
  LATB = 2
end if

delay_ms(500)
LATA = 0
LATB = Testvar

while TRUE           ' warten auf WDT
wend

end.