Komisches Verhalten - XMega16D4 läuft nicht mehr an

Timo Fischer Gast #3916701
Lesenswert?
• ▲
▼ 
Hallo liebes Forum,

wir haben für ein Studienprojekt eine Leiterplatte mit einem ATXMega16D4 
designt und ca. 50 Muster bestücken lassen. Die Beschaltung des ATXMega 
wurde wie in der Application Note vorgegeben gemacht. Taktquelle ist ein 
externer Quarz.

Der Controller wurde über ein Batchfile mit einer Testsoftware 
programmmiert, die verschiedene Frequenzen auf verschiedenen Ports 
ausgibt. Alle Platinen wurden getestet und liefen einwandfrei. Nun haben 
wir zwei Platinen dabei, wo das Programm nicht mehr startet. Erst wenn 
das Batchfile erneut ausgeführt wird, funktioniert die Leiterplatte 
wieder. Komisch dabei ist, dass beim ersten ausführen des Batchfiles bei 
den nicht funktionierenden Leiterplatten der Programmiervorgang 
ungewöhnlich lange dauert. Ca. 10mal solange wie sonst. Wenn der 
Controller wieder anläuft und das Batchfile erneut ausgeführt wird, ist 
die Dauer des Programmiervorgangs wieder normal.

Hat jemand ne Idee woran das liegen könnte? Bin etwas ratlos gerade.

Vielen Dank!
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Timo Fischer Gast #3916871
Lesenswert?
• ▲
▼ 
Nen Schaltplan hab ich leider gerade nicht zur Hand. Vcc und GND Pins 
sind aber auf jeden Fall alle angeschlossen. Kalte Lötstellen oder 
Brücken auch unter der Lupe nicht zu sehen. Fuses wie folgt:

Fusebyte0: 0x00
Fusebyte1: 0x00
Fusebyte2: 0xFF
Fusebyte4: 0xF3
Fusebyte0: 0xF7
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Timo Fischer Gast #3916969
Lesenswert?
• ▲
▼ 
Hab im Moment keine Leiterplatte bei der das Problem auftritt, da ich 
die beiden ausgefallenen ja neu programmiert habe und diese seit dem 
wieder laufen. Und reproduzierbar ist der Fehler leider nicht.

Werde aber eine Hälfte der 50 Leiterplatten mit dieser Einstellung 
programmieren und die Tests weiter laufen lassen. Mal schauen ob der 
Fehler auch mit diesen Fusebiteinstellungen auftritt. Bin aber 
skeptisch, da der Watchdog ja im Programm gar nicht verwendet wird.

Vielleicht ist das Problem ja auch ein defekter Chip. Habe nämlich 
Probleme beim verifizieren des EEPROMS, da stimmt der ausgelesene Wert 
nicht dem geschriebenem überein.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Matthias S. (Firma: matzetronics) #3917029
Lesenswert?
• ▲
▼ 
Timo Fischer schrieb:
> Habe nämlich
> Probleme beim verifizieren des EEPROMS, da stimmt der ausgelesene Wert
> nicht dem geschriebenem überein.

Zur XMega A-Serie gabs darüber eine Errata, die ein Beschreiben des 
EEPROMs praktisch nur im Sleep Mode erlaubte (was für mich der Grund 
war, ein 93C46 extern ranzuhängen), das sollte bei der D-Serie aber 
eigentlich gefixt sein.

Zum Originalproblem - der Reset Eingang der XMegas ist deutlich 
empfindlicher als der bei den AVR, Abhilfe sollte hier ein 
mittelkräftiger Pullup sein (10k-47k). Es schadet vermutlich auch nicht, 
PDI sinnvoll abzuschliessen und ihn nicht frei zu lassen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren