ATtiny84 nach Programmieren defekt?

[Tobias R. (to_r)]

Hallo!

Ich verwende einem USBasp um einen Atmel ATtiny84A über die Arduino IDE 
zu programmieren. Dabei tritt ab und zu folgender Fehler auf:

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x08cf
0x68 != 0xa9
avrdude: verification error; content mismatch

Nach einem erneuten Programmierversuch läuft danach meistens alles 
wieder ohne Probleme. Jedoch habe ich mittlerweile den dritten 
ATtiny84A, der nach diesem Fehler überhaupt nicht mehr reagiert:

% avrdude -c usbasp -p attiny84 -B 10

avrdude: set SCK frequency to 93750 Hz
avrdude: error: programm enable: target doesn't answer. 1 
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude done.  Thank you.

Gehen die ATtinys durch einen Programmiervorgang so einfach kaputt? Oder 
gibt es noch eine Möglichkeit den ATtiny wiederzubeleben?

Viele Grüße
Tobias

[Edi R. (edi_r)]

Tobias R. schrieb:
> Gehen die ATtinys durch einen Programmiervorgang so einfach kaputt?

Ganz sicher nicht, zumindest nicht mit einem Programmer, der nicht 
selber defekt ist.

Tobias R. schrieb:
> Oder gibt es noch eine Möglichkeit den ATtiny wiederzubeleben?

Dazu müsste man erst wissen, was damit tatsächlich passiert ist. Leider 
fehlen uns sämtliche Infos dazu. Die Fehlermeldung allein reicht nicht.

[Tobias R. (to_r)]

Edi R. schrieb:
> Dazu müsste man erst wissen, was damit tatsächlich passiert ist. Leider
> fehlen uns sämtliche Infos dazu. Die Fehlermeldung allein reicht nicht.

Gerne liefere ich weitere Infos. Jedoch fehlt mir momentan der 
Ansatzpunkt für weitere Nachforschungen. Welche Informationen könnten 
denn hilfreich sein, um die Ursache herauszufinden?

[Bernd K. (prof7bit)]

Tobias R. schrieb:
> Edi R. schrieb:
>> Dazu müsste man erst wissen, was damit tatsächlich passiert ist. Leider
>> fehlen uns sämtliche Infos dazu. Die Fehlermeldung allein reicht nicht.
>
> Gerne liefere ich weitere Infos. Jedoch fehlt mir momentan der
> Ansatzpunkt für weitere Nachforschungen. Welche Informationen könnten
> denn hilfreich sein, um die Ursache herauszufinden?

2 spontane Einfälle:
* Hast Du irgendwas an den Fuses gemacht (Reset, Clock, Debugwire, 
etc.)?
* Frei fliegender Drahtverhau + Programmiersockel (oder Steckbrett) + 
Wackelkontakt?

[Edi R. (edi_r)]

Tobias R. schrieb:
> Dabei tritt ab und zu folgender Fehler auf:

Wegen dem "ab und zu" tippe ich weniger auf die Fuses, eher auf:
- ISP-Takt zu hoch, oder
- Versorgung passt nicht

Aber es ist eben nur ein blindes Stochern im Nebel.

[Tobias R. (to_r)]

Bernd K. schrieb:
> * Hast Du irgendwas an den Fuses gemacht (Reset, Clock, Debugwire,
> etc.)?

Da die ATtiny84A mit 1 MHz ausgeliefert werden, habe ich ihn initial auf 
8 Mhz umgestellt:

avrdude -pattiny84 -cusbasp -e -Uefuse:w:0xFF:m -Uhfuse:w:0xD7:m -Ulfuse:w:0xE2:m -B 10

Danach habe ich an den Fuses nichts mehr geändert.

Bernd K. schrieb:
> * Frei fliegender Drahtverhau + Programmiersockel (oder Steckbrett) +
> Wackelkontakt?

Der Microcontroller ist über einen IC Test Clip mit dem USBasp verbunden 
(siehe Anhang). Ein Wackelkontakt sollte da eher unwahrscheinlich sein 
oder?

Edi R. schrieb:
> - ISP-Takt zu hoch, oder
> - Versorgung passt nicht

Der ISP-Takt wird vom USBasp doch automatisch ermittelt, wenn man diesen 
nicht explizit vorgibt oder? Das scheint im Normalfall auch problemlos 
zu funktionieren:

avrdude: usbasp_initialize()
avrdude: usbasp_spi_set_sck_period(0)
avrdude: auto set sck period (because given equals null)
avrdude: usbasp_program_enable()
avrdude: AVR device initialized and ready to accept instructions

Bei den "defekten" ATtinys bringt selbst ein starkes Herabsetzen des 
Taktes jedoch keine Änderung:

% avrdude -vvv -c usbasp -p attiny84 -B 100

avrdude: usbasp_initialize()
avrdude: usbasp_spi_set_sck_period(0.0001)
avrdude: try to set SCK period to 0.0001 s (= 10000 Hz)
avrdude: set SCK frequency to 8000 Hz
avrdude: usbasp_program_enable()
avrdude: error: programm enable: target doesn't answer. 1 
avrdude: initialization failed, rc=-1

Die Versorgung erfolgt über den USBasp und war auf 3.3 V eingestellt. 
Ein Umstellen auf 5 V bringt bei den "defekten" ATtinys auch keine 
Änderung.

Kann denn ein zu hoher ISP-Takt oder eine falsche Versorgung den 
ATtiny84A beim Programmieren in diesen "defekten" Zustand bringen?

[Bernd K. (prof7bit)]

Ich hab auch schon Programmiersockel/Breakout-Boards ählich diesem 
(exemplarischer Link, anderer Hersteller, nicht dieser: 
https://www.adafruit.com/product/1282) in den Fingern gehabt bei denen 
einzelne Pins (und zwar dort wo man es nicht sofort von außen sieht) 
nicht korrekt verlötet waren. Die haben jahrelang funktioniert, so lange 
bis aus heiterem Himmel und nur sporadisch mysteriöse Fehlermeldungen 
("target doesn't answer") auftraten.

Die Anweisung von avrdude "double check connections" sollte also ruhig 
mal etwas penibler ausgeführt werden, wirklich mal in aller Ruhe 
hinsetzen, noch nen Kaffee trinken, und dann ganz in Ruhe jeden 
einzelnen Pin kontrollieren, durchmessen, dran wackeln, etc.

[Bernd K. (prof7bit)]

Tobias R. schrieb:
> Der Microcontroller ist über einen IC Test Clip mit dem USBasp verbunden
> (siehe Anhang). Ein Wackelkontakt sollte da eher unwahrscheinlich sein
> oder?

Ich sehe daß Du mit den preisgünstigen vorkonfektinierten 
Steckbrett-Drahtbrücken (männlich-mannlich), erhältlich bei eBay 
arbeitest.

Da hatt ich kürzlich ne ganze Ladung bei denen war (obwohl optisch nicht 
zu erkennen) das blanke Metall am ende mit einem *hauchdünnen 
transparenten Kunststoff-Film überzogen*! Das waren wohl Reste der 
Isolierung oder weiß der Geier, optisch nicht zu erkennen, erst nach 
abkratzen mit dem Fingernagel erkenntlich.

[Fabian F. (fabian_f55)]

@ alle: Don't feed the troll...

A) Zu 90% Warscheinlichkeit ein Wackelkontakt oder falsches pinning.

B) Nimm einen original Programmierer von Atmel! Programmieren hat schon 
genug Tücken. Da muss man sich nich noch zusätzliche Probleme 
ranschaffen mit so einem billig-Programmierer. Die 20€ die man da spart 
sind es nicht wert. Ich hab einen AVRISP-Mk2 und einen JTAG ICE MKIII 
zum debuggen. Seit 6 Jahren noch nie probleme beim programmieren gehabt.

[Bernd K. (prof7bit)]

Fabian F. schrieb:
> Ich hab einen AVRISP-Mk2 und einen JTAG ICE MKIII
> zum debuggen.

JTAG-ICE lass ich gelten (debugging) aber zum Orginal AVRISP-Mk2 kann 
man gespaltener Meinung sein. Wenn er einen funktionierenden USBasp 
(oder irgendeinen anderen Programmierer der funktioniert) hat gibt es 
nicht den geringsten Vorteil wenn er sich zusätzlich noch einen AVRISP 
zulegt. Mehr als funktionieren kann der ohnehin nicht (und weniger 
Features (5V / 3.3V versorgen) und einen häßlichen Bug (Reset) hat er 
obendrein).

Ich tippe auf die abenteuerliche Verkabelung als Ursache.

[Tobias R. (to_r)]

Bernd K. schrieb:
> Ich tippe auf die abenteuerliche Verkabelung als Ursache.

Die Verkabelung ist zugegebenermaßen verbesserungswürdig. Jedoch konnte 
ich auch nach mehrmaligen Messen aller Pins keine Kontaktprobleme 
zwischen USBasp und den betroffenen ATtiny feststellen. Sobald ich mit 
dem IC Test Clip einen anderen ATtiny anschließe, bekommt der USBasp 
auch problemlos eine Verbindung.

Wie kann es also zu diesen Totalausfällen kommen? Was kann durch einen 
Wackelkontakt beim Programmieren passiert sein? Können die Fuses sich 
dadurch geändert haben?

[Jörg W. (dl8dtl) (Moderator)]

Tobias R. schrieb:
> Wie kann es also zu diesen Totalausfällen kommen?

Wie weit ist denn der nächste Abblockkondensator von deinem Controller
entfernt?

Bernd K. schrieb:
> Mehr als funktionieren kann der ohnehin nicht (und weniger Features (5V
> / 3.3V versorgen) und einen häßlichen Bug (Reset) hat er obendrein).

Naja, zwischen einem preiswerten USBasp und einem AVRISPmkII liegen
Welten: ISP-Geschwindigkeit (klar, natürlich nur, wenn der Controller
genügend schnell getaktet wird), saubere Pegelanpassung über den
gesamten Versorgungsspannungsbereich, Erkennung kurzgeschlossener
Programmier-Pins.  Keine Ahnung, was dein vermeintlicher Reset-Bug
sein soll.

[Tobias R. (to_r)]

Jörg Wunsch schrieb:
> Wie weit ist denn der nächste Abblockkondensator von deinem Controller
> entfernt?

1-2 mm. Befindet sich auf dem Board direkt neben dem VCC- und GND-Pin 
des Controllers.

[Jörg W. (dl8dtl) (Moderator)]

Tobias R. schrieb:
> Befindet sich auf dem Board direkt neben dem VCC- und GND-Pin des
> Controllers.

OK, das sollte wohl genügen.

Ich glaube, dann musst du mehr Details liefern über Schaltung, Aufbau
und dergleichen.

[Peter X. (peter_x)]

To Bias: Mach ein Bild von Deinem Aufbau!

[Tobias R. (to_r)]

Peter Xuang schrieb:
> To Bias: Mach ein Bild von Deinem Aufbau!

Ein Bild des Aufbaus befindet sich bereits oben in meinem Beitrag 
#3894728: 
https://www.mikrocontroller.net/attachment/237686/attiny84a_usbasp.jpg.

Jörg Wunsch schrieb:
> Ich glaube, dann musst du mehr Details liefern über Schaltung, Aufbau
> und dergleichen.

Bei dem Board, auf dem sich der ATtiny84A-PU befindet, handelt es sich 
um ein TinyTX3 (http://nathan.chantrell.net/tinytx-wireless-sensor/). 
Hier ist ein Schaltbild des Boards: 
http://nathan.chantrell.net/downloads/arduino/tinytx3/tinytx3_schematic.png
Der einzige Unterschied zu meinem Aufbau ist, dass ich anstelle des 
RFM12B ein RFM69CW verwende, welches jedoch Pinkompatibel zum RFM12B 
ist.

Beim Programmieren war wie im obigen Bild lediglich der USBasp an den 
Controller angeschlossen.

[Bernd K. (prof7bit)]

> Bei dem Board, auf dem sich der ATtiny84A-PU befindet, handelt es sich
> um ein TinyTX3 (http://nathan.chantrell.net/tinytx-wireless-sensor/).

Wenn Du den Tiny vom diesem board runternimmst und nackt ohne irgendwas 
an den USBasp anschließt, geht es dann wieder?

[Georg G. (df2au)]

Nach dem ersten Programmieren wird dein RFM bedient und stört 
nachfolgend die Kommunikation zwischen Programmer und Tiny. Ich hatte 
das gleiche Problem mit einem ATMega128 und RFM70. Die Lösung waren zwei 
Jumper in MOSI und MISO.