MSP430 - Programmabstutz erzeugen

[Tony _. (tony_s)]

Hello!

Ich möchte gerne das Verhalten des MSP430 ausprobieren, wenn am Port A
ein PWM generiert wird und sich das Programm irgendwo verirrt.

Wie könnte ich das machen?

[Tenner (Gast)]

wo liegt der sinn?

versuch's mit nem bufferoverflow.

gruß
Tenner

[Weinga-Unity (Gast)]

Vielleicht mit Rekursion?

[Jankey (Gast)]

jmp ins Nirgendwo?

[Johnny (Gast)]

Warum soll sich das Programm irgendwo hin verirren?

[HomerS (Gast)]

Deine PWM wird auf einem zufälligen Wert stehenbleiben, wenn keine neuen
   Werte ankommen. Fail-Save muß dahinter sein.

ts

[Jörg S. (Gast)]

Hab bisher noch keine PWM mit dem MSP gemacht, aber läuft das nicht
vollautomatisch im Timer Block ab? Wenn ja würde das auch weiter laufen
selbst wenn der "Core" hängen bleibt.
Erst ein Reset oder ein zufälliges beschreiben der Timer Register würde
die PWM abschalten/ändern.

[SupaChris (Gast)]

Bei einem ordentlich programmiertem Projekt springt dann der WDT an und
macht einen Reset des Systems.

[Tony _. (tony_s)]

Hoppla, heisse Diskussion...

Warum ich auf diese - vielleicht komische - Idee gekommen bin ist
folgende: Das PWM Signal erzeugt ein Steuersignal für einen DC Motor
(ca. 100W). Und weil eben der Timer automatisch läuft, habe ich die
Auffassung, dass dieser auch bei einem Absturz in Nirvana weiter läuft,
natürlich sehr unschön ist.
Watchdog ist nicht erwünscht, weil ein Fehler von aussen quittiert
werden muss (reset).

Und warum sollte ein Programm nicht einmal abstürzen?
1. Defekte Speicherzeile in Flash, also ein Adresse die sehr selten
angespruchen wird. Dies könnte man eventuell mit einer CRC Berechung
beim Aufstarten abfangen.

2. Wie wäre es mit einem ESD Schaden nach einiger Zeit ( > 6 Monate)

3. Einfach mal ein halb defekter Chip

usw.


Zu diesem Statement:
Deine PWM wird auf einem zufälligen Wert stehenbleiben, wenn keine
neuen Werte ankommen. Fail-Save muß dahinter sein.

Sprich: HW, die das am Leben sein des MSP überprüft?

Wäre für weitere Gedanken dankbar.

Tony_S

[szimmi (Gast)]

Hmmm,
waere vielleicht ein zweiter Controller (geschickterweise kein MSP)
anstelle des Watchdogs eine Lösung? Dieser überwacht Deinen MSP und
generiert im Fehlerfall eine Meldung nach oben bzw. greift in die
Steuerung des Motors ein.

[Jörg S. (Gast)]

Da hätten wir wieder das schöne Problem das aber auch der 2. Controller
abstürzen kann und feherhaft in den Motor eingreiffen könnte.

[szimmi (Gast)]

Ja,es muessen sich die beiden halt gegenseitig überwachen. Und das beide
gleichzeitig abstuerzen...

[Peter D. (peda)]

"Watchdog ist nicht erwünscht, weil ein Fehler von aussen quittiert
werden muss (reset)."

Und was spricht dagegen ?

Hat der MSP etwa kein Watchdogresetbit, welches anzeigt, daß ein
Watchdogreset erfolgte ?

Bei den AVRs kann man jedenfalls die Resetquelle ermitteln und
dementsprechend unterschiedlich behandeln.


Peter

[Frank (Gast)]

Also ich bin bisher immer davon ausgegangen, dass die in so einem
Controller integrierte Watchdoghardware genau für solche Fälle da
eingebaut wurde. Testen tu ich sowas mit ner eingeschalteten Magnastat
und einem Piezo-Gasanzünder sowie einem alten Blitzgerät aus
DDR-Produktion wenn grad keine EMV-Kanmer verfügbar ist. Damit bekommt
man fast jeden Selbstbau aus dem Tritt und kann den Wachhund prima
testen.

bye

Frank

[SupaChris (Gast)]

Beim Reset durch den WDT wird natürlich ein Bit gesetzt, dass einen
solchen Reset erkennbar macht. Ebenso wie bei Spannungseinbruch usw.
Das halte ich für die sinnvollste Möglichkeit. Da kann man beim
Programmstart das Bit abfragen, und dann die Quittierung ermöglichen.