Ursache für ATtiny13 "Massensterben" gesucht

[radbruch]

Hallo

Nachdem über eine Woche das ISP gut funktionierte (mysmartusb (http://www.myavr.de/shop/article.php?artDataID=36), avrdude (v2.0) (http://www.mikrocontroller.net/articles/AVRDUDE) und avr8 burn-o-mat(v1.4.2b) (http://avr8-burn-o-mat.aaabbb.de) unter w2k im Attiny-Testplatinchen (http://www.loetstelle.net/projekte/tinydil/tinydil.php)), kann ich inzwischen drei meiner ATtiny13 nicht mehr ansprechen:


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

Rechtschreibung im Titel korrigiert

[robocat]

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

[radbruch]

Hallo

Danke für die schnelle Antwort.


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.


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.


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.


vielleicht kann man den fehler eingrenzen.
Das wäre super, denn auf die Dauer ist mir das zu kostspielig und nervig.

Gruß

mic

[oberallgeier]

Hi, mic,

... oder sterben die generell leicht? ...
Kann ich wirklich nicht sagen, (ich bin noch IMMER NUR mit dem/den tiny13 beschäftigt) denn:

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


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


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

[Hubert.G]

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.

[radbruch]

Hallo


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.



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

[Besserwessi]

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?name=PNphpBB2&file=viewtopic&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.

[radbruch]

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.


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:


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

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


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 (http://myavr.de/shop/article.php?artDataID=56) 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

[izaseba]

Hallo Radbruch,

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

[radbruch]

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:


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

wird so übersetzt:

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

[Gock]

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ß

[radbruch]

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

[oberallgeier]

Hi, mic,




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,

[radbruch]

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):


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