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

Re: Ursache für ATtiny13 "Massensterben" gesuchet

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

Hi!
Was hast Du denn alles angeschlossen?
Ich habe mir letzte Woche einen Tiny zerschossen, weil ich ein Display am USI hatte und gleichzeitig geflasht. Erst hat alles funktioniert, dann häuften sich die Fehlermeldungen und nach dem 10ten Flash war er hinüber.
Allerdings muss auch ich sagen, dass die Dinger sehr empfindlich sind gegenüber falscher Versorgungsspannungen.
Gruß

Hallo

Der optimierte Takt oben beträgt natürlich nur 1MHz.

Angeschlossen sind:

Pin1 (reset): 10K gegen Vcc
Pin2 (adc3): analoger Eingang2, Taster gegen GND,
Pin3 (adc2): analoger Eingang1
Pin4 (gnd): GND
Pin5,6,7: Servoimpulse über 2,2k
Pin8 (Vcc): Vcc

+ die Verbindungen zur ISP-Schnittstelle.

Zusätzlich noch 100nF zwischen Pin8+4, 100uF zwischen Ubatt und GND, 100nF parallel zum Schalter (der anstelle des Spannungsreglers eingebaut ist). Die 2,2k und der 100uF sind erst nach dem ersten "defekten" tiny eingebaut worden und haben scheinbar nichts gebracht.

Ich habe immer mehr die ADC-Eingänge im Verdacht. Diese werden über Spannungsteiler gespeist die blöderweise auf Ubatt hängen und deshalb nicht abgeschaltet werden. Zudem könnte die Spannung höher als Uref werden, weil zwischen Ubatt und Pin8 ein paar Brücken und der Schalter sind. Zudem sind die analogen Sensoren steckbar angebaut und beim Ein-/Ausstecken kann GND geöffnet sein bevor Ubatt geöffnet wird, dann liegt Ubatt an den ADC-Eingängen. Ich habe allerdings keine Bestätigung ob die tinys darauf wirklich so empfindlich reagieren.

Bevor ich deshalb den nächsten Attiny einstecke, werde ich

- eine Diode in die Spannungsversorgung schalten
- die Spannungsteiler für analoge Signale auf Vcc legen
- Schutzwiderstand vor die Spannungsteiler damit Spannung am Eingang immer kleiner Uref.
- Die IC-Fassung austauschen

Gruß

mic

Hi, mic,

Zitat:

Zitat von radbruch

Zitat:

Ich fürchte, das hilft Dir nicht WIRKLICH weiter

Doch, weil es belegt, dass es kein generelles Tiny-Problem ist. ..

Diese Anmerkung nur der Vollständigkeit halber: nun ist auch bei mir - nach fast 3 Monaten Programmiererei an ein- und demselben tiny13, meinem ersten tiny13, nach vielfachem und vielfältigem falschen Beschalten der Ausgangsports, der Arme in die ewigen Hardware-gründe gegangen. Aber ich bin sicher, dass ich die Gründe seines Hinscheidens kenne: es war offenbar ein kollektiver Selbstmord - zusammen mit meinem HDD. Dummerweise verschied er letzte Woche Freitag mit der (physikalischen) Systemplatte :(.

Nun meldet mir mein r-hardware-ISP-Dongle zusammen mit ponyprog seinen gesamten Speicher auf "FF".

Trotz allem, schönen Abend,

Hallo

Seit ich meine Testplatine vor dem Programmieren des tiny13 spannungsfrei mache, leben meine tinys deutlich länger. Obwohl ich eigentlich keine Spannung über den ISP-Stecker auf die Schaltung gebe (Vcc hat bei meiner 5 poligen Lösung gar keinen Pin), funktioniert es totzdem. Vermutlich reicht die Versorgung über den 10k-Widerstand am Resetpin? Das nur so nebenbei.

Eigentlich wollte ich folgendes mitteilen:

Heute habe ich mal im Datenblatt gestöbert und folgendes unter der Beschreibung des Watchdogs gefunden (Seite 37/38):

Zitat:

Note: If the Watchdog is accidentally enabled, for example by a runaway pointer or
brown-out condition, the device will be reset and the Watchdog Timer will stay enabled.
If the code is not set up to handle the Watchdog, this might lead to an eternal loop of
time-out resets. To avoid this situation, the application software should always clear the
Watchdog System Reset Flag (WDRF) and the WDE control bit in the initialisation routine,
even if the Watchdog is not in use.

Sinngemäss bedeutet das: Wenn durch irgendeinen unglücklichen Umstand, z.B. durch einen wildgewordenen Zeiger oder eine Niederspannungsbedingung, der Watchdog aktiviert wird, könnte der Kontroller in eine endlose (timeout-)Resetschleife gelangen. Dieser Zustand wird immer bestehen bleiben. (Dann ist der tiny13 tot!) Um das zu vermeiden, sollten auch Anwendungen, die den Watchdog nicht verwenden, diesen trotzdem bei der Initialisierung ausschalten.

Das habe ich hier im RN-Forum noch nie gesehen, werde es aber in Zukunft beachten. Die paar "verschwendeten" Bytes ist mir das wert.

Übrigens hat der tiny13 in Wirklichkeit zwei Timer, denn der Watchdog kann beim tiny13 nicht nur einen Reset ausführen, er kann im Gegensatz zum Mega8/32 auch nur einen Interrupt auslösen. Mit eigenem Takt-Oscillator (128kHz) kann je nach Prescaler alle 16ms bis 8Sek ein Interrupt ausgelöst und eine eigene ISR ausgeführt werden. Ich finde das prima, auch wenn ich noch nicht weiß, wie man das außer für ein Blinken oder eine echte Watchdogfunktion nutzen kann.

Gruß

mic