Hardwareschaden durch Software? // Externen Takt einspeisen
Hallo,
mir sind gestern anscheinend zwei AVRs kaputt gegangen und ich weiß nicht so recht warum.
Ich habe drei Boards: Ein original RN Control 1.4, und zwei daran angelehnte Nachbauten. Bei einem dieser neuen Boards hab ich bemerkt, dass er sich anscheinend die Fusebits nicht zuverlässig merkt: Ich habe einen Quartz verwendet und deshalb für den Takt die "111111" gewählt. Das angeschlossene LED-Dotmatrix-Display funktionierte zunächst. War der Strom aber längere Zeit unterbrochen, dann konnte man beim Multiplexen direkt zusehen - irgendwie schien er mir auf die Verwendung des internen Taktgebers zurückzufallen, und manchmal auch nach einigen Sekunden doch wieder den externen zu verwenden.
Als ich dann ein wenig mit den Fusebits spielte schaltete ich irgendwie auf einen externen Oszillator um und nix ging mehr natürlich.
Ich hab dann mit einem NE-555 einen kleinen Taktgenerator aufgebaut und das Signal über XTAL-1 eingespeist. Ich musste ein wenig experimentieren (verschiedene Kondensatoren und Widerstände) aber, siehe da, das Display leuchtete wieder (wenngleich ich das Zeitverhalten nicht ganz nachvollziehen kann).
Als ich dann aber die Fusebits wieder umprogrammieren wollte, ging das aber nicht. Ich vermutete dann, dass wahrscheinlich der NE zu langsam taktet. Da kam ich auf die Idee, einfach das andere Board als Taktgenerator zu verwenden:
Code:
int main(void)
{
// Port C ist Ausgang
DDRC = 0xFF;
while (1) //Endlosschleife
{
PORTC = 0xFF;
PORTC = 0xFF;
PORTC = 0xFF;
PORTC = 0xFF;
PORTC = 0xFF;
PORTC = 0xFF;
PORTC = 0xFF;
PORTC = 0xFF;
PORTC = 0xFF;
PORTC = 0xFF;
PORTC = 0x00;
}
}
Dann verband ich die beiden Massen durch die Gehäuse der Festspannungsregler auf beiden Boards und speiste von einem der PortC-Ausgänge des einen Boards das Signal in XTAL-1 des Streikenden ein. Das ging auch, das Programm lief jetzt deutlich schneller also zuvor mit dem NE-555-Takt. Dennoch ließen sich die Fusebits nicht programmieren.
Also änderte ich das Programm geringfügig:
Code:
int main(void)
{
// Port C ist Ausgang
DDRC = 0xFF;
while (1) //Endlosschleife
{
PORTC = 0xFF;
PORTC = 0x00;
}
}
Doch irgendwie ging jetzt gar nix mehr. Ich schloss dann mal LEDs an den Port C an - dunkel. "Biste wohl an einen falschen Pin gekommen beim Takteinspeisen und hast den AVR geschossen" dachte ich. Vor der Transplantation des noch verbleibenden Prozessors vom RN-Control auf das selber gebaute Board klemmte ich alles zum anderen Board ab und lud das Programm nochmal hoch. Die Leuchtdioden leuchteten kurz, blinkten kurz und dann war wieder alles dunkel. Jetzt hab ich offenbar zwei kaputte und einen streikenden ATMega.
Wie kann es sein, dass das oben genannte Programm zwei AVRs tötet? Mit beiden Boards habe ich schon mehrere kleine Programme ausprobiert und das ging immer einwandfrei.. versteckt sich im Schaltplan des Board, das ich als Taktgeber verwenden wollte, etwa ein kollossaler Fehler? Oder darf man einen Ausgangport nicht toggeln?
Gerry
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo,
ich hatte vorhin vergessen, den Schaltplan nochmal anzuhängen, nachdem ich das Posting zuerst unter "AVR" verfasst hatte und dann doch unter "Elektronik" posten wollte.
Auf dem Bord, auf dem's die AVRs geschossen hat ist kein Dotmatrix-Display, sondern nur eine LED-Reihe, die im Prinzip genauso angesteuert wird wie auf dem original RN Control, nur dass die über das Flachbandkabel an jeden Port anschließbar ist.
Das Dotmatrix Display auf dem zweiten Board ist ebenfalls mit entsprechenden Vorwiderständen angeschlossen. Damit gab's bisher auch keine Probleme. Auch im längeren Betrieb nicht (>3h)
Es muss irgendwas mit dem Programm in Kombination mit der Hardware zu tun haben...
