Hardwareschaden durch Software? // Externen Takt einspeisen

[Gerry77]

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:




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:


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

[kalledom]

Hallo Gerry,
hast Du zwischen Ausgängen und LED-Dotmatrix-Display Treiber ?
Die Ausgänge halten maximal 20mA Strom aus, aber nicht an mehreren Ausgängen gleichzeitig; dann wird die Gesamtverlustleistung des AVR überschritten.

[Gerry77]

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

[shaun]

Kaum, Du kannst programmieren, was Du willst. Die einzige Möglichkeit, die Hardware durch ein Programm zu beschädigen besteht darin, dass es softwareseitig erreichbare Zustände von Überspannung oder Überstrom gibt, also zB dass ein falsch gesetztes Portbit 12V auf einen AD-Eingang schaltet oder sowas, oder halt keine Strombegrenzungswiderstände. Dass Du die Fusebits nicht mehr ändern konntest wundert mich, komplett löschen geht auch nicht mehr? Spannungsversorgung stabil?

[Gerry77]

Hallo,

"Problem was located between keyboard and chair". Ich hab versehentlich bei beiden Prozessoren, die ich als Taktgeber einsetzen wollte, die falschen (zurückgelesenen) Fusebits vom verunglückten Prozessor reingeflashet. Das macht der BaseComm Programmer scheinbar, wenn man auf "Auto Program" clickt. Ich dachte, er überträgt nur die angezeigte Seite, und das war der Programm-Flash-Speicher. Konnte die beiden mit dem NE555-Taktgenerator retten. Bei dem anderen hab' ich mich leider selber ausgesperrt. (Lockbits) ](*,)

[SeaLion]

Die Lockbits sollten kein Problem sein, die lassen sich mit einem Chip-Erase wieder löschen.