-         

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 14

Thema: Ursache für ATtiny13 "Massensterben" gesucht

  1. #1
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    54
    Beiträge
    5.781
    Blog-Einträge
    8

    Ursache für ATtiny13 "Massensterben" gesucht

    Anzeige

    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]

    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  2. #2
    Erfahrener Benutzer Roboter Genie Avatar von robocat
    Registriert seit
    18.07.2006
    Beiträge
    935
    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

  3. #3
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    54
    Beiträge
    5.781
    Blog-Einträge
    8
    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

    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  4. #4
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    7.551

    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.
    Ciao sagt der JoeamBerg

  5. #5
    Erfahrener Benutzer Robotik Visionär Avatar von Hubert.G
    Registriert seit
    14.10.2006
    Ort
    Pasching OÖ
    Beiträge
    6.183
    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.

  6. #6
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    54
    Beiträge
    5.781
    Blog-Einträge
    8
    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

    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  7. #7
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    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.

  8. #8
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    54
    Beiträge
    5.781
    Blog-Einträge
    8
    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:

    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

    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  9. #9
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.05.2005
    Ort
    Issum
    Alter
    45
    Beiträge
    2.236
    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

    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
    Software is like s e x: its better when its free.
    Linus Torvald

  10. #10
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    54
    Beiträge
    5.781
    Blog-Einträge
    8
    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

    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •