AVR DRAGON HVSP mit ATtiny13A. Keine Funktion

Matthias Laubnitz schrieb:
> Wie kann ich
> es testen?

Anderen ATtiny13 reinsetzen?

Matthias Laubnitz schrieb:
> Den
> Controller habe ich auch gewechselt

Leuchten am Dragon noch alle LEDs? Riecht es vielleicht streng?

Ja es leuchten noch alle (zwei) LEDs. Nein, es riecht nicht.

Vielleicht ein Kabelbruch oder eine Brücke im Programmierkabel?

Wie könnte ich prüfen ob das Board ein Problem hat?

Ohne Schaltplan und adäquate Messmittel wird das schwierig. Hast Du mal 
am Reset-Pin gemessen (Oszi!), ob während des Programmierens 12V 
´rauskommen?

Also der Reset Pin geht auf +5V und nicht höher. Allerdings folgen nach 
der steigenden Flanke auf +5V noch 3 kleine Peaks auf 5,1V.

Meinst du den Schaltplan vom Dragonboard?

Dann ist vielleicht der Spannungswandler für die 12 V hinüber.  Es
ist aber schwierig auszumachen, welche Bauteile dafür genau zuständig
sind.

Sicherheitshalber die Frage: eine Schutzdiode hast du aber nicht aus
Versehen an den /RESET vom ATtiny13 geschaltet, oder?

Jörg Wunsch schrieb:
> Sicherheitshalber die Frage: eine Schutzdiode hast du aber nicht aus
> Versehen an den /RESET vom ATtiny13 geschaltet, oder?

Nein. Wie gesagt ich habe ja die ganze Zeit programmieren können.

Wo ist die Geschwindigkeit einzustellen beim HVSP Verfahren?

Ich habe vor kurzem das selbe Problem mit zwei tiny85v in Verbindung mit 
meinem STK500 gehabt. Beim automatischen Verify kam immer die selbe 
Fehlermeldung. Interessanterweise landete das zu schreibende Programm 
trotzdem immer im Flash.

Die Ursache würde mich allerdings auch interessieren.

Konntest du denn die Fuse Bits richtig auslesen? Bei mir kommt das 
nämlich auch immer 0xff

Matthias Laubnitz schrieb:
> Konntest du denn die Fuse Bits richtig auslesen? Bei mir kommt das
> nämlich auch immer 0xff

Pruuust....

Muss dazu mal eben mein Equipment wieder ausbuddeln. Melde mich in ca. 
15 Minuten wieder...

AAAARRGH !!!   Es ist zum aus der Haut fahren!

Hab gerade noch mal mein STK500 und einen ATtiny85v (mit dem es beim HVP 
Probleme gab) angestöpselt. Jetzt lässt er sich wieder ohne Gemecker 
brennen.

Die Konfiguration ist die Selbe wie zum Zeitpunkt des Fehlverhaltens. 
Selbes STK, selber Tiny, selbes Netzteil, selbe RS232 Strippe, selbes 
Notebook.

Hmmm.... mir fällt gerade ein:   Es hat sich in der Zwischenzeit doch 
etwas geändert...

Mein Virenscanner hat letztens bei einem kompletten Systemcheck drei 
Viren entdeckt und entfernt. Vielleicht hatte es ja was damit zu tun.

Lass doch vorsichtshalber auch mal nen kompletten Virenscan laufen. 
Womöglich hast du dir ja auch was eingefangen?

Ich muss meine Aussage nun doch revidieren:

Das Verifyproblem besteht bei mir doch nach wie vor. Habe eben gesehen, 
dass ich damals einfach das Häkchen bei "Verify" rausgenommen hatte. Das 
Verifying war auch bei meinem heutigen Test um 20:00h noch deaktiviert. 
Mit eingeschaltetem Verify wird selbiges mit einem Fehler abgebrochen.



Die Signatur wird bei mir korrekt ausgelesen.

Fuses können auch ausgelesen und geschrieben werden.

Lock Bits sind nicht gesetzt.

VTarget beträgt 5V.

Versorgung des STK500 über Steckernetzteil 12V/500mA. Spannung ist 
während des gesamten Vorgangs stabil (mit Oszi überprüft).



P.S.:  Es ist offensichtlich allmählich mal wieder an der Zeit für ein
       paar Tage Erholungsurlaub ;)

Habe mittlerweile ein zweites Dragonboard. Wenn ich einen leeren 
ATtiny13 funktioniert alles wunderbar. Setze ich die Fuse Bit auf High 
Byte: 0xFE und Low Byte: 0x61 funktioniert nichts mehr. Aber ich arbeite 
doch im HVSP Verfahren. Ich verstehe das nicht

Setze ich den das FuseBit Reset Pin disable läuft gar nicht mehr. Warum?