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!
Brownout aktiviert? Wenn ja, Boardspannung überprüfen.
Hallo Knut, Danke für die schnelle Antwort. Brownout ist aber deaktiviert. Die "start-up time" ist auf den höchsten Wert gestellt und die Spannung am Board ist stabil.
Hast Du einen Schaltplan? Wie stehen die Fuses? Kalte Lötstellen oder Brücken? Alle GND / VCC - Pins angeschlossen?
:
Bearbeitet durch User
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
Setze FuseByte1 mal auf 0x88.
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.
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.
Hallo Matthias, Danke für den Tip. Ein 10K Pullup am Reset ist vorhanden. PDI hingegen liegt leider offen.......
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.