Hi leute,
ich sitze jetzt schon seit zwei tagen an einem problem, unzwar verliert
meine software immer seine variablen ... nach einiger überlegung binn
ich darauf gekommen, das das mc wieder in der main anfängt :-(( und ich
habe im moment noch nicht so richtig den paln, von wo er diesen
"softreset macht" :'-(( Hat von euch euch jemand einen plan wie ich das
rausfinden kann ? Ich benutze Insight, weiß jemand ob und oder wie ich
villeicht festtellen kann, aus welcher routine mein mc rausgesprungen
ist bzw. welcher mein zuletzt ausgeführter code war ?!
MfG Stepan
ich kenne den MSP430 nicht, aber vielleicht hat der auch irgendwo ein
Register, wo man verschiedene Bits hat, obs ein externer, ein Power-On,
ein Brown-Out oder Watchdog-Reset war.
Wenn dort kein Bit gesetzt ist, dann hat dein Programm gesponnen,
ansonsten hast Du die Resetquelle.
Typische Fehler bei solchen Software-Resets sind die Verwendung von
Pointern, die in den Wald zeigen oder ein Stack-Overflow.
Das man bei einem MC rekursive Funktionen meiden soll, wie der Teufel
das Weihwasser, weißt Du.
Die fressen ja regelrecht den Stackspeicher auf.
Peter
stimmt, ich habe mal irgentwas von solcheinem register gelesen ...
vielleicht finde ich auch noch raus wie es heißt :-P
Weißt du wie ich einen Stack-Overflow erkennen kann ?
thx Peter für die schnelle antwort !
Also beim 8051 mache ich das so, daß ich den gesamten Stack mit 0x77
initialisiere.
Und nach einem Reset mache ich eine RAM-Dump über die UART, da sieht man
dann schön die 77 oder eben nicht, wenn der Stack übergelaufen ist. Bzw.
man kann auch einschätzen wieviele 77 übrig sind, also der Stack noch
Reserve hat.
Der RAM-Dump muß natürlich erfolgen, bevor der RAM gelöscht bzw. mit 77
beschrieben wird.
Dazu muß man die Startdateien des C-Compilers etwas modifizieren. Beim
8051 heißt sie "startup.a51", wo man die Löschroutine auskommentieren
kann.
Anbei ein 8051 Beispiel.
Peter
Schalte mal am Anfang von main den Watchdog aus...
WDTCTL = WDTPW +WDTHOLD; // Stop WDT
Hatte das selbe Problem, habe auch ein paar Stunden hinterhergesucht.
Viel Erfolg!
den Watchdog habe ich schon ausgeschalte ... aber trotzdem danke ;-)
Was mir auch sehr komisch vorkommt, ist das wenn ich einzelschritte
mache, ich keine probleme habe. Erst wenn ich ihn selber weiterlaufen
lasse, springt er sofort wieder zur main. Allerdins läuft er ohne prob.
weiter wenn ich über den kommandozeiten gdb continue eingebe :-/
Stephan,
Versuch doch mal, mit dem CSPY-Debugger von IAR zu debuggen.
Mit objcopy ein HEX-File erzeugen, dass kann der CSPY auf das Target
runterladen. Dann kannst Du zwar nur auf Assembler-Ebene debuggen, aber
immerhin.
Mit dem Insight-Debugger habe ich auch schon einige merkwürdige
Erfahrungen gemacht...
Hallo Stepan,
uU. ist ein nicht initialisierter Interrupt Vektor Schuld daran. Belege
vorsichtshalber unbenutzte Interruptvektoren mit einer Adresse zu einem
"IRET" Befehl. Auf diese Weise wird zwar immer noch ein Interrupt
initiiert, aber wenn auf dem IRET-Befehl ein Breakpoint liegt, kannst du
mitkriegen, ob es an einem nicht initialisierten Interrupt Vektor liegt.
Gruß,
Claus
Eine eigene Frage?
Dieser Thread ist über 23 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
