Forum: Mikrocontroller und Digitale Elektronik ATXMEGA32E5 Input Capture Problem


von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

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?

von Rainer U. (r-u)


Lesenswert?

Ist ja schon seltsam. Und das das Signal schnell prellt und somit 
irgendwie weggefiltert wird? Oder ist das Signal extrem hochohmig?

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

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... :-(

von Rainer U. (r-u)


Lesenswert?

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!

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

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!

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

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.

von Rainer U. (r-u)


Lesenswert?

Na wie vermutet - prima selbst ausgetrickst! :-) Aber ist ja auch ein 
schönes Gefühl, wenn man es gefunden hat und die Welt wieder in Ordnung 
ist ;-)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.