Hallo Forum,
bei einem aktuellen Projekt habe ich einen Timer (TCD5) für Input
Capture konfiguriert, und zwar im "Frequency and pulse width capture"
Modus. Es klappt alles soweit gut, nur dass sporadisch Capture
Interrupte fehlen. Das Abtasten des Signals erfolgt mittels Event System
vom Portpin auf beide Signalflanken inklusive 8-Clock-Filter, das Signal
ist auch nachweislich da (Logic-Analyzer läuft mit). Im Programm ist
nichts, was die Interrupte aufhalten könnte, 99% kommen immer
punktgenau, jittern nicht und kommen auch nicht verpätet. Einzelne
kommen, wie gesagt, gar nicht. Was meint ihr: Bug oder Brett vorm Kopf?
Hallo Rainer,
danke für Deine Wortmeldung.
Rainer U. schrieb:> Und das das Signal schnell prellt und somit> irgendwie weggefiltert wird?
Nee, das Signal ist absolut sauber, kommt von einem anderen Controller
und wird stetig überwacht.
Rainer U. schrieb:> Oder ist das Signal extrem hochohmig?
Nö, die Flanken sehen gut aus. Ich messe am empfangenden Controllerpin.
Inzwischen glaube ich eher an ein Softwareproblem, aber ich konnte es
noch nicht finden. Ich lasse die durchgegangenen Interrupte numerische
Signale auf einem Pin ausgeben, der ebenfalls am LA hängt, um zu
kontrollieren, welcher nicht gefeuert hat. Seltsamerweise ist es jetzt
immer der letzte von 4 aufeinanderfolgenden, der sporadisch ausbleibt,
das war schon mal anders. Und das geschieht auch nur, wenn der
abzutastende Puls einer logischen "1" entspricht, also mit 60µs doppelt
so lang ist, als die 30µs lange "0". Was mich doch ziemlich irritiert,
da beim XMEGA durch die Event-Steuerung bis zum Interrupt-Flag alles in
Hardware läuft, wenn es denn erst einmal korrekt konfiguriert ist.
Das wird dann wohl ´ne längere Debug-Session... :-(
Naja ich kenn das, manchmal trickst man sich prima selbst aus. Als
Denkanstöße fällt mir noch ein:
- detektiert er wirklich immer beide Flanken, oder ist der Abstand
zwischen 2 steigenden zufällig passend??
- läuft während des Captures ein Timer "über" (wird der in der ISR auf 0
gestellt?)
- was passiert, wenn man den "Filter" weglässt"
Viel Glück!
Rainer U. schrieb:> Naja ich kenn das, manchmal trickst man sich prima selbst aus.
Hmm - passiert schon mal...
Rainer U. schrieb:> detektiert er wirklich immer beide Flanken
Muss er, beim XMEGA gibt es da Einstellungen, die das komplett
automatisieren, dabei folgt auf eine steigende Flanke immer eine
fallende und umgekehrt. Die positiven Pulse landen in CCA und die
negativen in CCB.
Rainer U. schrieb:> läuft während des Captures ein Timer "über" (wird der in der ISR auf 0> gestellt?)
Überlaufen dürfte (!) der eigentlich nicht, weil ich PER vor dem
Aktivieren der Capture-Funktion auf 0xFFFF stelle was 655ms entsprechen
würde. Das 0-Stellen macht der XMEGA selbsständig.
Rainer U. schrieb:> was passiert, wenn man den "Filter" weglässt"
Genau das Gleiche. Mist ist halt, dass die Fehler sporadisch, daher
unregelmäßig und nicht reproduzierbar sind... Alle vermeintlichen
Probleme in der Software habe ich schon angefasst. Muss ich heute abend
nochmal ´reingucken, ob der Aha-Effekt eintritt. Falls ja, werde ich die
wahre Ursache posten.
Vielen Dank trotzdem!
Jaaaa.... was soll ich sagen? Der XMega macht alles richtig. Das Problem
befand sich wie immer zwischen den Ohren des Anwenders. Ich habe für ein
Debug außerhalb des zuständigen Capture-Interrupts das CCB-Register
gelesen und dabei natürlich den just in Diesem Moment eingetragenen
Timestamp gelöscht. Somit kam das Interruptflag nicht und ein Puls wurde
verpennt. Da das Debug asynchron zu den Interrupts läuft, war es rein
zufällig, dass beide mal so direkt zusammentreffen, dass zwischen
Eintrag des Timestamps in CCBBUF und dem Lesen von CCB nur 1 Zyklus lag.
Wieder was gelernt.
Danke an alle, die den Schmarrn mitgelesen haben und nicht den selben
Fehler machen.
Eine eigene Frage?
Dieser Thread ist über 10 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
