Programm startet ca. alle 5 bis 10 Minuten neu.

[Michel R. (rtv_ruoss)]

Hallo zusammen,
mein PIC32MX7 Projekt mit einem Cerebot MX7 Pro von Digilent läuft 
eigentlich soweit ohne Probleme.
Doch leider startet scheinbar der Controller alle ca. 5 bis 10 Minuten 
neu.
Ich hab den Code nochmals durchgestöbert und finde bis jetzt keinen 
Hinweis auf diesen Fehler.

Ich verwende das MPLAB-X 3.15 mit dem XC32 Compiler 1.40.

danke für jeden Input oder Idee woran es liegen könnte.

Gruss

[Klaus (Gast)]

Michel R. schrieb:
> Doch leider startet scheinbar der Controller alle ca. 5 bis 10 Minuten
> neu.

Klingt für mich nach Memory Leak

MfG Klaus

[Horst (Gast)]

Falls Hardwaretechnische Probleme nicht ausgeschlossen sind, ist 
Überhitzung gerne ein Problem mit solch komischen Intervallen...

[Sebastian S. (amateur)]

Ich würde mich Klaus anschließen.

Also die Speicherreservierungen ins Auge fassen.

Eine weitere Möglichkeit ist
schau' Dir mal alle Zugriffe in Form von:
Variable [ ?? ] = ?? an.

Wird nur gelegentlich darauf zugegriffen und der Index flippt aus, so 
ist die Chance groß, dass Du irgendwann den Stapel erreichst (z.B. nach 
einigen Komma fünf Minuten) und den Prozessor ins Nirwana schickst.

Oft landet das Programm dann hinter dem programmierten Speicher, läuft 
dann bis zum Ende durch und beginnt wieder bei 0000(0). In vielen 
Systemen ist das aber gleichbedeutend mit einem Reset.

[Michel R. (rtv_ruoss)]

Hallo Sebastian,
Du meinst meinen zugriff mit dem Display Array?

Sebastian S. schrieb:
> Ich würde mich Klaus anschließen.
>
> Also die Speicherreservierungen ins Auge fassen.
>
> Eine weitere Möglichkeit ist
> schau' Dir mal alle Zugriffe in Form von:
> Variable [ ?? ] = ?? an.
>

Hab mir auch schon überlegt wie ich das eleganter lösen könnte.
Leider hab ich bisher noch keine Idee gehabt wie.
Evtl mit einer Lokal Variable. den der Inhalt hab ich mit eienr Routine 
ja auf max einen 3Stelligen Wert in einen String einfügen begrenzt.

[oszi40 (Gast)]

Michel R. schrieb:
> Ich hab den Code nochmals durchgestöbert und finde bis jetzt keinen
> Hinweis auf diesen Fehler.

Dann setze z.B. ein paar Prüfpunkte und schau was nach 10 Minuten 
passiert.
Der Möglichkeiten gibt es viele wie Speicherüberlauf, RAM-Fehler, Wärme, 
Netzteil, angeschlossene Leitungen usw. ...

[Sebastian S. (amateur)]

Ich habe mir Deinen Code nicht reingezogen.

Wenn Du irgendwo eine Deklaration hast in der Form:
byte Etwas [ 20 ];

und dann später mit z.B.
for (Ix=0;Ix<=20;Ix++)
{
 Etwas [ Ix ] = KeineAhnung;
}

so lässt Dir der Compiler das problemlos durchgehen.

Auch wenn Du dabei auf Etwas [ 20 ] zugreifst...

[Purzel H. (hacky)]

Erst mal Funktionalitaet rausschmeissen, resp abschalten, bis der Fehler 
nicht mehr auftaucht, dann wieder langsam reinfuellen.

[Mark B. (markbrandis)]

Klaus schrieb:
> Michel R. schrieb:
>> Doch leider startet scheinbar der Controller alle ca. 5 bis 10 Minuten
>> neu.
>
> Klingt für mich nach Memory Leak

Es wird nirgendwo im Code dynamisch Speicher reserviert.


Sebastian S. schrieb:
> Ich habe mir Deinen Code nicht reingezogen.
>
> Wenn Du irgendwo eine Deklaration hast in der Form:
> byte Etwas [ 20 ];
>
> und dann später mit z.B.
> for (Ix=0;Ix<=20;Ix++)
> {
>  Etwas [ Ix ] = KeineAhnung;
> }
>
> so lässt Dir der Compiler das problemlos durchgehen.
>
> Auch wenn Du dabei auf Etwas [ 20 ] zugreifst...

Dies scheint hier ebenfalls nicht der Fall zu sein. Im selbst erstellten 
Teil des Codes gibt es ein:

volatile char Display[16];

Die Zugriffe darauf erfolgen mittels sprintf() und es sieht zumindest 
auf den ersten Blick nicht so aus, als ob an irgendeiner Stelle über die 
Grenzen des Arrays hinaus geschrieben wird.

Es existieren noch weitere Arrays im Code, aber die stammen aus 
eingebundenem Fremd-Code à la "Graphics Driver Library". Der Code sollte 
also wohl okay sein, ich nehme an dass der so auch anderswo eingesetzt 
wird und nicht solche Probleme bereitet.


oszi40 schrieb:
> Michel R. schrieb:
>> Ich hab den Code nochmals durchgestöbert und finde bis jetzt keinen
>> Hinweis auf diesen Fehler.
>
> Dann setze z.B. ein paar Prüfpunkte und schau was nach 10 Minuten
> passiert.
> Der Möglichkeiten gibt es viele wie Speicherüberlauf, RAM-Fehler, Wärme,
> Netzteil, angeschlossene Leitungen usw. ...

...oder ein aktiver und womöglich falsch konfigurierter Watchdog, falls 
der Neustart immer nach der gleichen Zeitspanne auftritt.

[Stefan F. (Gast)]

Es könnte auch einfach ein Stack Überlauf sein, der auftritt, wenn zu 
viele Ereignisse gleichzeitig auftreten.

[Michel R. (rtv_ruoss)]

Mark B. schrieb:

> Die Zugriffe darauf erfolgen mittels sprintf() und es sieht zumindest
> auf den ersten Blick nicht so aus, als ob an irgendeiner Stelle über die
> Grenzen des Arrays hinaus geschrieben wird.

Das war auch mein erster Gedanke, doch mache ich auch keine malloc 
Speicher reservation und daher hab ich dass mal als unwahrscheindlich 
beiseite geschoben.

> Es existieren noch weitere Arrays im Code, aber die stammen aus
> eingebundenem Fremd-Code à la "Graphics Driver Library". Der Code sollte
> also wohl okay sein, ich nehme an dass der so auch anderswo eingesetzt
> wird und nicht solche Probleme bereitet.

Ja die Libary wird so vom Board Hersteller bereitgestellt. Habe nur die 
Port zuweisungen modifiziert das es auf meinem Board läuft.


> ...oder ein aktiver und womöglich falsch konfigurierter Watchdog, falls
> der Neustart immer nach der gleichen Zeitspanne auftritt.

Werde mal versuchen den WDT generell zu deaktivieren. Hab aber keinen 
mit wissen eingerichtet.

Auch werde ich den Code auf Speicherrelevate Variablen durchsuchen und 
versuchen zu optimieren.

Danke Gruss

[Twinsetter (Gast)]

Also ich würde auch auf Watchdog tippen, wenn das Teil einen solchen hat 
(ich kenne diesen Chip nicht). Ich würde den Watchdog generell 
abschalten, es sei denn gewichtige Gründe sprechen dagegen.

Gruß Twinsetter

[Ralph (Gast)]

Nimm einen Debugger / Jtag, oder wie immer das Ding für die PIC heißt.

Dann einen Breakpoint auf den Resetvektor setzen und laufen lassen.

Wenn dann nach ein paar Minuten das ganze am Breakpoint steht, kannst du 
über die Register raus finden wo der Programcounter gestanden hat als es 
zum Reset gekommen ist.

Damit weißt du dann wo und warum es kracht.
Alles andere ist rumstochern im Nebel.

[Michel R. (rtv_ruoss)]

Ralph schrieb:

> Dann einen Breakpoint auf den Resetvektor setzen und laufen lassen.
>
> Wenn dann nach ein paar Minuten das ganze am Breakpoint steht, kannst du
> über die Register raus finden wo der Programcounter gestanden hat als es
> zum Reset gekommen ist.

Gute Idee, danke nur leider bin ich mit dem Debugger nicht so auf gut 
Fuss, im Sinne wie kann ich den Breakpoint auf den Reset setzen?

Ich danke für Deine Unterstützung

[A. Horn (Gast)]

Hast du schon mal ein Mini-Programm ausprobiert?
Vielleicht nur eine Tastenabfrage (o.ä.), dann eine LED blinken lassen.
(so dass du erkennst, wenn ein Reset ausgeführt wurde)
(vielleicht auch nur eine "Start"-Debug-Ausgabe über die serielle
Schnittstelle)
Dann sollte sich einkreisen lassen, ob es am Programm selbst
liegt oder etwas, was im Startup freigeschaltet wird bzw.
vielleicht sogar bedingt durch die Hardware.
Vielleicht schlägt auch etwas in deine Spannungsversorgung
oder dein Reset-Controller löst einen Reset aus?
Ich hatte mal ein Problem (ist aber schon lange her),
bei dem der Controller immer wieder mal beim Einschalten
des Brenners unserer alten Heizungsanlage einen Reset ausgelöst hatte...
(oder auch Starter einer Lampe mit Neonröhre)

[Ralph (Gast)]

Michel R. schrieb:
> Gute Idee, danke nur leider bin ich mit dem Debugger nicht so auf gut
> Fuss, im Sinne wie kann ich den Breakpoint auf den Reset setzen?

Da musst du dich mal mit deiner IDE befassen.
Mit PIC und der Microchip IDE hab ich noch nichts gemacht. Kann die so 
nicht sagen wo sich die passenden Buttons/Menupunkte verbergen.

Ralph

[Michel R. (rtv_ruoss)]

Hallo zusammen,
hab nochals die Config Bit Kontrolliert und musste merken das ich folge 
#pragma falsch gesetz hatte.

Fehlte:
#pragma config FWDTEN = OFF // Watchdog timer enable

Dadurch ist der Watchdog per default ON.

Ich danke für eure Unterstützung.

Werde die Anmerkungen aber betreffend Speicherhandling im 
weiterenverlauf berücksichtigen.


Ich danke euch für die breite Unterstützung.