Forum: Compiler & IDEs Seltsame neustarts


von ich (Gast)


Lesenswert?

Hallo

Ich habe ein mega128can basiertes projekt samt code übernommen und habe 
nach kleinen erweiterungen seltsame neustarts.

Die neustarts werden scheinbar durch die software verursacht da MCUSR == 
0 ist.

Das seltsame daran ist, dass die software scheinbar fehlerfrei läuft 
direkt nach dem flashen per ispmk2.

Bei späteren starts/power cycles kommt es reproduzierbar zu abstürzen.

Beim init wird ein per realloc generiertes array mit callbacks gefüllt.
Der rest ist statisch.
Interrupts werden erst nach dem init freigegeben.
Die uart ausgaben werden per printf gemacht.
In keiner ISR wird printf verwendet.

Beim versuch zusätzlichen debug code hinzuzufügen scheint das Problem zu 
verschwinden.
Wobei ich nicht glaube, dass es weg ist.

Jemand eine idee wo/wie ich mit der Fehlersuche ansetzten kann?

von Masl (Gast)


Lesenswert?

Wenn ich Mega128 lese (ohne 4P am Schluß) stellen sich mir sofort die 
Nackenhaare auf.
Thema: 103-Kompatibility Fuse.

Allerdings, anscheinend hast du ja einige Interrupts bevor dein uC 
abschmiert. Beim 103-er Problem würde nach Ende der ersten ISR dein uC 
schon neu gestartet.

von Uwe S. (de0508)


Lesenswert?

Moin,

ja mit dem veröffentlichen von Schaltplan, Bildern vom gesamten Aufbau 
und dem gesamten Programm - das wäre mal etwas !

von ich (Gast)


Lesenswert?

@Masl:
nur gut dass ich die CAN variante hab.
Der hat nämlich kein 103 compat fuse bit...

@Uwe:
Da hat mein Auftraggeber etwas dagegen :-/

von Tobias Hagemeier (Gast)


Lesenswert?

Hi,

drei Möglichkeiten (wobei ich das MCUSR-Byte mangels Datenblatt gerade 
einfach mal ignoriere):

- Interrupt ohne Interrupt-Handler. Der landet im Standardfall auf dem 
Reset-Vektor. Such mal nach BAD ISR (oder ähnlich). Es lässt sich für 
alle Interrupts ohne Handler eine gemeinsame Routine definieren (die 
z.B. einfach nur ein RETI enthält).
- Watchdog - sollte aber über das Flag relativ eindeutig 
diagnostizierbar sein
- Sprung an eine Adresse hinter dem Belegten Flash oder 0. In dem Fall 
würde auch das MCUSR-Register nicht verändert werden. 0xFF im Flash wird 
als NOP behandelt. Der Controller läuft dann bis zum Ende des Flash und 
macht bei 0 weiter - dem Reset-Vektor. Auch wenn alle Funktions-Pointer 
stimmen (etc) kann sowas vorkommen wenn z.B. ein Array "zu groß" mit 0 
initialisiert wird. Dann ist ganz schnell die Rücksprungadresse auf dem 
Stack auf 0 gesetzt und genau dahin gehts dann nach der Ausführung der 
Funktion zurück.

Da einen eindeutigen Fehler zu finden wird natürlich ohne Code schwer, 
auch mit Code vermutlich nicht leicht ;) Insofern sind auch die drei 
Möglichkeiten natürlich auch nicht mehr als das. Guck mal, was du davon 
ausschließen kannst..

Gruß,
Tobi

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.