Hilfe zur Selbsthilfe: Temporärer Fehler debuggen

[Johannes (Gast)]

Hallo alle zusammen!

Im Rahmen meines Praktikums habe ich eine kleine Firmware für den MSP 
geschrieben. Der MSP reagiert auf ein "Triggersignale" und aggiert nach 
Ablauf einer bestimmten Zeit darauf. Auf dem ersten Blick sah alles 
wunderprächtig aus. Nun habe ich habe bei längerem Messen mit dem 
Oszilloskop festgestellt, dass die Reaktion ab und zu zu früh kommt. 
Leider ist das ganze nicht deterministisch und so ist es nicht möglich 
einfach mal nur einen Breakpunkt im Code zu setzen.

Kann mir jemand einen Tipp geben, wie ich es schaffe den Zeitpunkt zu 
debuggen, in der die Reaktion zu früh kommt?

Vielen Dank für eure Hilfe.

Gruß
Johannes

[Volker Z. (vza)]

Zum Debuggen braucht man drei Dinge:

1. gutes Werkzeug (Debugger,Emulator,Oszi etc.) Welche stehen Dir zur 
verfühgung?

2. systematisches Vorgehen.  Setze/lösche an markanten Stellen ein 
Port-Pin um die zeitliche Abfolge im Programm zu messen . zB. beim 
starten des Timers.  Wie gross ist die Abweichung?

3. Erfahrung.  Du könntest dein Quelltext hier zeigen.

Volker

[Johannes (Gast)]

Hallo Volker!

Danke für deine Antwort.
Zu deinen Rückfragen:
1. Entwicklungsumgebung Ti CCE, Ti Debug-Interface MSP-FET430UIF
2. Genau ein Haupttimerüberlauf. Hierzu folgende Info:
TimerB0 = Haupttimer, dieser macht den Haupttakt von 500µs (im 
Continousmode), TimerB1 = Timer für die Reaktion. Wenn TimerB1 = 3300µs 
werden 6 Überläufe des TimersB0 gezählt und dann TimerB1 mit den Ticks 
für 300µs gestartet. Nun kommt meine Reaktion nicht bei 3300µs sondern 
eben bei 2800µs.
3. Erfahrung sammle ich gerade. Und Quelltext geht nicht. Da würde ich 
Ärger mit meinem Betreuer oder einer noch höherer Führungskraft 
bekommen...

Gruß
Johannes

[Läubi .. (laeubi)]

Johannes schrieb:
> Und Quelltext geht nicht. Da würde ich
> Ärger mit meinem Betreuer oder einer noch höherer Führungskraft
Und wieso fragst du dann nicht gleich deinen Betreuer oder ein noch 
höhere Führungskraft ob sie dir helfen kann?

Johannes schrieb:
> Genau ein Haupttimerüberlauf
Dann wirst du wohl irgendwo im Code den Timmer nicht korrekt verwenden 
(reset/preset ohne ausschalten von interrupts o.ä.)

[Volker Z. (vza)]

Wenn der Timer B1 mit 500µs getacktet wird, hast Du immer einen Jitter 
von max. 500µs. Du weist ja nicht ob du den Timmer B1 kurtz vor oder 
kurtz nach dem Überlauf setzt.
Timmer läst man mit der max. möglichen Frequenz laufen, damit der Jitter 
möglichst klein wird.

Volker

[Karl (Gast)]

Läubi .. schrieb:
> Und wieso fragst du dann nicht gleich deinen Betreuer oder ein noch höhere 
Führungskraft ob sie dir helfen kann?

Sein Vorschlag war halt Breakpoints. Aber da es jede x-hunderteste Event 
ist wo das passiert, ist das eben nicht so einfach.

Volker Zabe schrieb:
> Wenn der Timer B1 mit 500µs getacktet wird, hast Du immer einen Jitter
>
> von max. 500µs. Du weist ja nicht ob du den Timmer B1 kurtz vor oder
>
> kurtz nach dem Überlauf setzt.

Ich würde vestehen, wenn der Timer +500µs jittert, aber nicht -500µs. 
Und zwar ausschließlich -500µs.

[Oliver (Gast)]

Ohne Quelltext wird das nichts.

Und ohne den Prozessor jetzt im Detail zu kennen, wäre eine Vermutung 
eine race condition bei Rücksetzen deines Überlauf-Zählers, oder was in 
der Art.

Oliver

[Volker Z. (vza)]

Karl schrieb:
> Ich würde vestehen, wenn der Timer +500µs jittert, aber nicht -500µs.
> Und zwar ausschließlich -500µs.

Doch, verkürzen ist schohn richtig. Du setzt den neuen Wert immer vorm 
Decrementieren. Im schlimmsten Fall dauert das erste 500µs-Intervall 
eben nur 10ns.

Das mit dem "ausschließlich" verstehe ich allerdings auch nicht.
Aber wie kommt er auf exakt 3300µs bei 500µs Takt.
300µs Latenz zwischen Trigger und setzen des Timmers sind erstens etwas 
lang und zweitens dürften die auch nicht konstant sein.

Fragen über Fragen!!! (an den Quelltext)

@TO
mach doch mal eine Messreihe. Vieleicht kommt man dan auf den 
Fehler(art).

Volker