Ursache für ATtiny13 "Massensterben" gesucht

Hallo

Nachdem über eine Woche das ISP gut funktionierte (mysmartusb, avrdude (v2.0) und avr8 burn-o-mat(v1.4.2b) unter w2k im Attiny-Testplatinchen), kann ich inzwischen drei meiner ATtiny13 nicht mehr ansprechen:

Code:

---

C:\WinAVR\bin\avrdude.exe -q -u -C C:\WinAVR\bin\avrdude.conf -p t13 -P com2 -c avr910 -E noreset,novcc  -U flash:w:C:\attiny\projekte\attiny.hex:a
avrdude.exe: WARNING: -E option not supported by this programmer type

Found programmer: Id = "AVR ISP"; type = S
    Software Version = 2.3; Hardware Version = 2.0
Programmer supports auto addr increment.

Programmer supports the following devices:
    Device code: 0x1c = ATtiny11
    Device code: 0x55 = ATtiny12
    Device code: 0x01 = ATtiny13
    Device code: 0x56 = ATtiny15
    Device code: 0x13 = AT90S1200
    Device code: 0x28 = AT90S4414
    Device code: 0x20 = AT90S2313
    Device code: 0x4c = AT90S2343
    Device code: 0x30 = AT90S4433
    Device code: 0x6c = AT90S4434
    Device code: 0x38 = AT90S8515
    Device code: 0x68 = AT90S8535
    Device code: 0x41 = ATMEGA103
    Device code: 0x46 = ATMEGA64
    Device code: 0x44 = ATMEGA128
    Device code: 0x03 = AT90CAN128
    Device code: 0x75 = ATMEGA16
    Device code: 0x74 = ATMEGA644
    Device code: 0x63 = ATMEGA162
    Device code: 0x64 = ATMEGA163
    Device code: 0x79 = ATMEGA169
    Device code: 0x14 = ATMEGA329
    Device code: 0x15 = ATMEGA3290
    Device code: 0x16 = ATMEGA649
    Device code: 0x17 = ATMEGA6490
    Device code: 0x72 = ATMEGA32
    Device code: 0x60 = ATMEGA161
    Device code: 0x76 = ATMEGA8
    Device code: 0x77 = ATMEGA8
    Device code: 0x3b = ATMEGA8515
    Device code: 0x6a = ATMEGA8535
    Device code: 0x5e = ATTINY26
    Device code: 0x29 = ATTINY261
    Device code: 0x2a = ATTINY461
    Device code: 0x2b = ATTINY861
    Device code: 0x06 = ATMEGA48
    Device code: 0x07 = ATMEGA88
    Device code: 0x08 = ATMEGA168
    Device code: 0x21 = ATtiny2313
    Device code: 0x09 = AT90PWM2
    Device code: 0x0a = AT90PWM3
    Device code: 0x22 = ATtiny25
    Device code: 0x23 = ATtiny45
    Device code: 0x24 = ATtiny85
    Device code: 0x0b = ATMEGA640
    Device code: 0x0c = ATMEGA1280
    Device code: 0x0d = ATMEGA1281
    Device code: 0x18 = ATMEGA2560
    Device code: 0x19 = ATMEGA2561
    Device code: 0x25 = ATtiny24
    Device code: 0x26 = ATtiny44
    Device code: 0x27 = ATtiny84
    Device code: 0x1a = AT90USB1286
    Device code: 0x1b = AT90USB1287
    Device code: 0x4b = ATMEGA325
    Device code: 0x4d = ATMEGA645
    Device code: 0x4e = ATMEGA3250
    Device code: 0x4f = ATMEGA6450

avrdude.exe: AVR device initialized and ready to accept instructions
avrdude.exe: Device signature = 0x000000
avrdude.exe: Yikes!  Invalid device signature.
            Double check connections and try again, or use -F to override
            this check.


avrdude.exe done.  Thank you.

---

Obwohl ich immer brav ausschalte beim Umstöpseln, alle externen Anschlüsse trenne, die Versorgungsspannung wie immer ist und der Reset-Impuls am Pin1 gemessen werden kann, reagieren die uCs nicht mehr.

Mache ich einen grundsätzlichen Fehler oder sterben die generell leicht? Oder ist meine Versorgungsspannung zu hoch (fast 5,5v bei frisch geladenen NIMH-Mignons).

Bisher habe ich nur flash- und eeprom-Daten übertragen und die fuses nicht verändert. Fummelt vielleicht avrdude an den fuses ohne das ich es will? Wie kann ich feststellen, was mit dem tiny nicht stimmt? Bei unverändertem Aufbau kann ich nach dem Tausch des defekten uCs sofort wieder flashen.

Ich hoffe, ihr könnt mir einen Tipp geben. Im Web finde ich nur Probleme und Lösungen beim Einrichten von ISP beschrieben. Hinweise auf unerklärlich "Zerschosse"(kein fuses-Fummeln, keine nicht funktionierende Betaktungen u.ä.), wie es bei mir der Fall ist, habe ich bisher noch nicht gefunden.

Gruß

mic

[Edit]Rechtschreibung im Titel korrigiert[/Edit]

hi radbruch,

die 5,5V sind noch grade so im rahmen, ich denke nicht, dass es daran liegt. bei welcher gelegenheit verabschieden sich denn die tinys? mitten im betrieb, oder nach dem flashen?

da du ja mit servos herumbastelst: hast du 1k widerstände in den signalleitungen? (ohne ist mir mein mega32 hier zusammengeklappt, sobald die servos belastet wurden)

laut datenblatt gehen 40mA / pin bei insgesamt 200mA. kannst du messen, wieviel strom bei dir fliesst? wäre auch interessant, ob die toten tinys noch strom aufnehmen.

vielleicht kann man den fehler eingrenzen.

gruesse

Hallo

Danke für die schnelle Antwort.

Zitat:

---

bei welcher gelegenheit verabschieden sich denn die tinys? mitten im betrieb, oder nach dem flashen?

---

Die "sterben" wohl beim flashen. Da ich keinen Simulator habe, flashe ich beim Debuggen meiner Programme eigentlich recht häufig nacheinander. Das funktioniert auch tagelang, bis eben plötzlich der Prozessor nicht mehr reagiert. Weder das Programm (was immer da drin ist nach einem Flashfehler) noch ISP funktionieren dann noch.

Zitat:

---

hast du 1k widerstände in den signalleitungen?

---

In der ersten Version waren die Servosignale direkt an den Pins angeschlossen. Nach dem ersten defekten ATtiny habe ich nun 2,2k in den Signalleitungen.

Zitat:

---

kannst du messen, wieviel strom bei dir fliesst?

---

Strom über Pin8(Vcc) zwischen 2,9 und 3,5 mA schwankend, Spannung an Pin8/1 sind 5,1irgendwasV. An den Ausgängen sind ca. 0,7-1,6V messbar.

Zitat:

---

vielleicht kann man den fehler eingrenzen.

---

Das wäre super, denn auf die Dauer ist mir das zu kostspielig und nervig.

Gruß

mic

Hi, mic,

Zitat:

---

Zitat von radbruch

... oder sterben die generell leicht? ...

---

Kann ich wirklich nicht sagen, (ich bin noch IMMER NUR mit dem/den tiny13 beschäftigt) denn:

Zitat:

---

Zitat von radbruch

... immer brav ausschalte beim Umstöpseln, alle externen Anschlüsse trenne, die Versorgungsspannung wie immer ist und der Reset-Impuls am Pin1 gemessen werden kann...

---

Alles Dinge die ich nie tue - also nicht in letzter Konsequenz. Meine tiny13 hab ich schon öfters (eigentlich nie mit Absicht) hot unplugged, Widerstände vergessen, Vcc oder GND voll auf ports gelegt - und ich hab schon ich weiss nicht wie oft meinen "ersten" geflasht - und wenn ich denke er ist defekt - dann liegts blos an meinem schlechten, neuen Programmcode. Oder an den falsch angeschlossenen Servo´s - siehe unten.

Zitat:

---

Zitat von radbruch

... und die fuses nicht verändert ...

---

Zu den fusebits, ich ändere blos den internent Takt... nicht mehr. Mein Vcc ist wann immer ich es messe, unter 5,00 V, meist 4,97V mit meinem DVM - das macht der LP2950. UND - ich habe nicht die Platine, die Du benutzt.

Zitat:

---

Zitat von robocat

... da du ja mit servos herumbastelst: hast du 1k widerstände in den signalleitungen? (ohne ist mir mein mega32 hier zusammengeklappt, sobald die servos belastet wurden) ...

---

Meine ersten Servo-Versuche hatte ich auch mit direkt angehängten Servos gemacht. (Sorry, ich bin blutiger Elektronikanfänger und schnupper erst kurz in die AVR´s hinein). Fazit: nix geht, weil der tiny in Mikrosekunden an Auszehrung gestorben ist - die Energie blieb einfach weg. Vermutlich wurde der immer wieder geresetet, schaltete dann die Servos ein - Energie blieb weg - Reset - die Servos zitterten so zäh dahin und bewegten sich nicht wirlkich. Diesen Unfug hatte ich aber mit dem Oskar nicht wiederholen wollen.

Ich fürchte, das hilft Dir nicht WIRKLICH weiter - aber ich hätte nie gedacht dass die tiny´s so robust sind.

Hast du schon mal versucht an CLKI einen externen Takt anzulegen, wenn es beim flashen passiert liegt doch der Verdacht nahe das es was mit den Fuses zu tun hat.

Hallo

Zitat:

---

Ich fürchte, das hilft Dir nicht WIRKLICH weiter

---

Doch, weil es belegt, dass es kein generelles Tiny-Problem ist. Wie geschrieben fallen die bei mir nicht im Betrieb aus. Ob die Taktleitung der Servos mit oder ohne Widerstand am Tiny (oder ohne Widerstand am ATMega32 meines RP6) angeschlossen sind dürfte den uC nicht jucken. Auch bei blockierendem Servo sollte das Steuersignal nicht zusätzlich belastet sein, allerdings könnte dabei die Bordspannung eines Experimentierboards zusammenbrechen. Natürlich vergesse ich das Abstöpseln/Ausschalten auch gelegentlich, habe aber noch keinen Zusammenhang mit dem uC-Sterben erkannt.

Zitat:

---

Hast du schon mal versucht an CLKI einen externen Takt anzulegen

---

Nein, habe ich noch nicht versucht. Davon habe ich zwar schon gelesen, aber ich habe noch keine Ahnung, wie dieser externe Takt aussehen muss, welche Frequenz man benötigt und wie man in einfach erzeugt. Muss ich mich mal einlesen, als "Taktgenerator" hätte ich z.B. den RP6 mit seinem 8MHz-ATMega zur Verfügung. Einfaches toggeln eines Pins über Verzögerungsschleifen sollte damit bis in den MHz-Bereich möglich sein und würde meine Kentnisse nicht übersteigen. Mit den Timern/PWM bin ich noch auf Kriegsfuss.

Gruß

mic

Die im Link gezeigte Testplatine hat einen Spannunsgregler 78L05 eingezeichent. Wenn der drauf ist, könnten die 5,5 V am Eingang schon knapp sein. Müßte sonst ein low drop Regler drauf. Oder eventuell auch nur eine Diode oder 2.

Geht denn der ISP programmierer noch mit einer anderen Schaltung. Es könnte nähmlich duchaus auch ein Defekt am Programmmierer oder dem Kabel sein sein.

Das Programmieren per ISP ist nicht besonders zuverlässig weil die dazu benutzte SPI Schnittstelle eigentlich nur für kurze Leitungen und saubere Signal gedacht ist. Durch lange Kabel, schlechtes Platinenlayout usw, kann es mal passieren das das serielle Protokoll ein Bit verliert und dann ziehmlich unkontrolliert auch die Fuses verändert. Ein recht guter Link dazu (Englisch): http://www.avrfreaks.net/index.php?n...wtopic&t=36591
Ist zwar im wesenlichen über LPT Programmierer, aber die anderen haben eigentlich das selbe Problem.
AVRdude kontrolliert deshalb nach jedem Programmieren noch mal die Fuses und stellt sie ggf wieder her.

Der Externe Takt sollte etwa 500 kHz-1MHz betragen, gerade schnell genug um die standart ISP Frequenz zu unterstützen.

Hallo

Die Testplatine ist ohne Spannungsregler bestückt, weil ich sie nur für 4*1,2V konzipiert habe. Ein Diode in Reihe habe ich auch schon erwogen und werde ich einbauen. Da es mein erstes ISP-Projekt ist, habe ich noch keine weiteren Schaltungen zum Testen. Mein mysmartusb ist über ein normales USB-Kabel mit dem PC verbunden. Die Programmierleitung zur Testplatine ist ca. 30cm lang. Nach dem Wechseln der ATtinys funktioniert ja auch wieder alles für ein paar Tage.

Zitat:

---

AVRdude kontrolliert deshalb nach jedem Programmieren noch mal die Fuses und stellt sie ggf wieder her.

---

Wenn durch einen Übertragungsfehler ein fuse umgeschaltet wird und ich deshalb nicht mehr flashen kann, kann avrdude doch auch nicht mehr drauf zugreifen und es nach dem fehlerhaften Flashen automatisch korrigieren, oder?

Ich habe inzwischen ein 50cm Adapterkabel zwischen RP6 und Testplatine gelötet. Nun werden die (stabilisierten) 5V vom RP6 eingespeist und ein Takt erzeugt. Bei eingeschaltetem Takt habe ich dann 2,5V am Attiny13-Pin2, scheinbar das erwartete Recktecksignal, allerdings weiß ich ohne Oszi nichts über die genaue Kurvenform.

Und leider funktioniert es auch nicht. Vielleicht ist mein Takt falsch oder die Kurvenform zu schlecht. Mein Code:

Code:

---

        DDRA |= 16;                                // E_INT1 als Ausgang
        cli();
        while(1) PORTA ^= 16;

---

Schneller wirds wohl auch mit reinem Assembler nicht gehen, es wurde so übersetzt:

Code:

---

       
DDRA |= 16;                                // E_INT1 als Ausgang
 1bc:        d4 9a              sbi        0x1a, 4        ; 26
        cli();
 1be:        f8 94              cli
 1c0:        90 e1              ldi        r25, 0x10        ; 16
        while(1) PORTA ^= 16;
 1c2:        8b b3              in        r24, 0x1b        ; 27
 1c4:        89 27              eor        r24, r25
 1c6:        8b bb              out        0x1b, r24        ; 27
 1c8:        fc cf              rjmp        .-8              ; 0x1c2 <main+0xe>

---

Ich hab's mal nachgerechnet: Ein-/Ausgabe und das exclusive Oder je ein Zyklus, der relative Sprung zwei Zyklen ergibt 5 Takte je Toggle und 10 pro Periode, also einen externen Takt von 8MHz/10=800kHz.

Scheinbar haben die Tinys unterschiedliche Defekte: Bei zweien werden von avrdude die fehlerhaften Signature-Bytes meist mit 0xFF, aber gelegentlich auch mit anderen Werten gemeldet. Einer wird aber immer mit 0X00 in allen Bytes angemotzt. Hat vielleicht auch nichts zu bedeuten.

Für wenig Geld gibt's bei myavr.de noch einen passenden Programmierer für meinen USB-Adapter. Kennt den jemand und könnte ich meine Tinys damit wiederbeleben, wenn nur die Fuses verstellt sind. Vielleicht bietet auch mein Programmieradapter noch weitere Möglichkeiten. Ich muss mich da mal einlesen, was nervig ist, wenn man mitten im Projekt steckt und keine funktionierenden Tinys mehr hat.

Ich will ja echt nicht meckern, aber (Billig-)ISP ist schon recht zickig.

Gruß

mic

Hallo Radbruch,

Zitat:

---

Kennt den jemand und könnte ich meine Tinys damit wiederbeleben, wenn nur die Fuses verstellt sind.

---

Ich meine oben gelesen zu haben, daß Du nichts an Fusebits gemacht hast, deswegen verstehe ich nicht, warum sie auf einmal verstellt sein sollen 8-[

Daß avrdude die Fuses automatsch korigiert, halte ich für ein Gerücht, sorry.

Ich hatte bis jetzt nur einmal einen Vorfall, wo avrdude gemeldet hat, daß die Fuses nicht stimmen.
Da hatte ich den resetpin wegprogrammiert und versucht ISP zu programmieren.
Avrdude hat mich aber darauf aufmerksam gemacht, daß ich was ändern wolle, und die Änderung nicht wirksam wird, wie den auch ohne reset ;-)

Am sonsten kann ich Dir leider nicht helfen, so was habe ich bis jetzt wirklich nicht erlebt :-(

Gruß Sebastian

Hallo

Danke für die Anteilnahme und die Tipps. Mein Favorit ist im Moment die Versorgungsspannung. Ich habe irgendwo gelesen, dass die AVRs sehr empfindlich reagieren wenn am ADC eine höhere Spannung anliegt als die Referenz. Das könnte eventuell beim Einschalten passieren. Ich werde nun auf jeden Fall eine Diode in Reihe schalten um mehr Abstand zu den 5,5V zu bekommen.

Es geht natürlich immer besser, wenn man etwas tüftelt:

Code:

---

        DDRA |= 16;                                // E_INT1 als Ausgang
        cli();
        while(1)
        {
                x ^= 16;
                PORTA = x;
        }

---

wird so übersetzt:

Code:

---

        DDRA |= 16;                                // E_INT1 als Ausgang
 1bc:        d4 9a              sbi        0x1a, 4        ; 26
        cli();
 1be:        f8 94              cli
 1c0:        90 e1              ldi        r25, 0x10        ; 16
 1c2:        80 91 e6 00        lds        r24, 0x00E6
        while(1)
        {
                x ^= 16;
 1c6:        89 27              eor        r24, r25
                PORTA = x;
 1c8:        8b bb              out        0x1b, r24        ; 27
 1ca:        fd cf              rjmp        .-6              ; 0x1c6 <main+0x12>

---

Nur noch ein XOR, ein OUT und ein Sprung in der Schleife ergibt 4 Takte oder 2MHz externer Takt für den Tiny. Hab's aber noch nicht versucht, dürfte auch keine wesentliche Veränderung sein.

Gruß

mic