Programm Counter MSP430 auslesen

OP #923599
Lesenswert?

Hallo zusammen,

Brauche eure Hilfe.

Folgendes Problem. Seit kurzer Zeit stehen einige Automaten einfach 
still. Weder HW-Reset noch sonst was bringt Sie zum weiterlaufen. Da ich 
den Code leider nicht selbst geschrieben habe und nun das Projekt 
übernommen habe gestaltet sich die Fehlersuche schwierig. Ich möchte 
wissen wo die SW stehen bleibt. Kann ich dazu den PC auslesen? und somit 
auf die Stelle im SourceCode zurückschliessen?
Da ich nicht nachvollziehen kann wie ich in diesen Status komme nützt 
mir das Debuggen auch nichts da ich den Fehler ja nicht provozieren 
kann.

Hat vieleich jemand einen Tipp?
Kann ich den PC auslesen ohne dass ich den MSP neu Flashen muss?

MFG Fabio
Gast #923604
Lesenswert?

>Weder HW-Reset noch sonst was bringt Sie zum weiterlaufen.

Ein/Ausschalten auch nicht? Da würde ich den Fehler dann nicht
in der Software suchen ;) Es sei denn der flasht sich sein
eigenes Programm unter den Füssen weg.
Persönliche Seite #923608
Lesenswert?

Wenn das Programm "abstürzt", dann wird der PC darin irgendwas machen. 
"Stehenbleiben" tut die Software mit Sicherheit nicht, sie wird nur 
irgendwelche sinnarmen Schleifen durchführen.

Da man die MSP430-Familie vorzüglichst über JTAG debuggen kann, musst Du 
nur ein Entwicklungssystem an einen der stehenbleibenden Automaten 
anschließen und den Kram halt im Debugger laufen lassen.

Wenn das "Absturz"verhalten auftritt, hältst Du die ganze Chose an und 
kannst Dir den Stack, die Register und sonstige Speicherinhalte näher 
ansehen.
OP #923611
Lesenswert?

Danke für die prompte Antwort!

Das das Programm da sinnfreie Schleifen ausführt ist mir klar. Nur finde 
ich den Grund und den Ort dafür nicht!

Das Komische ist nur dass das ganze bis jetzt 1 Jahr ohne Probleme lief.
Ich kann ja schlecht 1 Jahr warten bis das ganze wieder auftaucht!
#923649
Lesenswert?

Also Debuggen ohne Flashen geht auch, mit MSPGCC zum Beispiel, ich glaub 
bei IAR geht das auch, muss man den Haken bei "Download" wegmachen. Dann 
siehst du zumindest den disassemblierten Code. Aber ob das was 
bringt....naja. Wenn du eh keinen Quelltext hast, bringen dir ja auch 
die Programm-Adressen nix.
OP #923695
Lesenswert?

Das ich den Fehler nicht Provozieren kann! Ich weiss nicht mit welcher 
Manipulation den "Fehler" verursacht. Wie rufus meinte:
Es könnte ja sein, daß die Software irgendwelche Kenndaten ins
InfoMemory schreibt, da mittlerweile Quark drinsteht und deshalb die
Software ins Straucheln gerät ...

Da die SW ja 1 Jahr ununterbrochen und ohne Probleme gelaufen ist stellt 
sich mir die Frage, soll ich 1 Jahr daneben stehen und den Debugger 
laufen lassen, bis es wieder passiert? =)
#923727
Lesenswert?

Nun ja, ob was ins InfoMem geschrieben wird, ist ja aus dem Quelltext 
ersichtlich.
Ansonsten halt mal Flash-Inhalt mit dem hoffentlich noch vorhandenem 
Binär-File vergleichen. Ich dachte der Fehler tritt jetzt ständig auf?
Wenn ja, wie gesagt, einfach das Flash-Schreiben abstellen und dann 
siehst du ja, wo die Kiste stehen bleibt.....besonders auf das Bit 
achten, das anzeigt, ob der WatchDog angesprungen ist....
Gast #923755
Lesenswert?

>Ansonsten halt mal Flash-Inhalt mit dem hoffentlich noch vorhandenem
>Binär-File vergleichen.

Also wenn der Vorgänger gut war, dürfte sich das als
schwierig erweisen den aktuellen Flashinhalt auszulesen.
Wenn ich Geräte ausliefere setze ich vorher die Codeprotection.

>soll ich 1 Jahr daneben stehen und den Debugger
>laufen lassen, bis es wieder passiert? =)

Du hast da ein echt grosses Problem.
Ich möchte jetzt nicht in deiner Haut stecken!

Laufen die Automaten denn wieder wenn du den Chip
komplett neu programmierst?

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren