MSP430 <- rest

Stephan Gast #40006
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Peter D. #40007
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stephan Gast #40008
Lesenswert?
• ▲
▼ 
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 !
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter D. #40009
Lesenswert?
• ▲
▼ 
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
Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stephan Gast #40011
Lesenswert?
• ▲
▼ 
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 :-/
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Klaus Sperlich Gast #40012
Lesenswert?
• ▲
▼ 
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...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Claus Krause Gast #40013
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren