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
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.