ATmega324a lässt sich nicht mehr programmieren nach Fuse setzen

[Tobias E. (tobinator)]

Hallo,

ich wollte das Programmieren mit Mikrocontrollern mal etwas besser 
verstehen und jetzt antwortet mein ATmega324a nicht mehr :(

Anfangs ging noch alles, ich konnte mit Atmel Studio 7 programmieren, 
dann wollte ich eine FUSE-Einstellung ändern. Ich habe "Int. 128kHz RC 
Osc." eingestellt. Direkt danach bekam ich die Fehlermeldung:

Failed to enter programming mode. ispEnterProgMode: Error status 
received: Got 0xc0, expected 0x00 (Command has failed to execute on the 
tool)

Unable to enter programming mode. Verify device selection, interface 
settings, target power, security bit, and connections to the target 
device.

Mit AVRdude habe ich auch schon rumprobiert, allerdings bekomme ich da 
auch keine Verbindung:

         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is 
"C:\avrdude-6.3-mingw32\avrdude.conf"

         Using Port                    : COM3
         Using Programmer              : STK500
         AVR Part                      : ATmega324P
         Chip Erase delay              : 55000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page 
Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages 
MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ 
----- ----- ---------
           eeprom        65    10   128    0 no       1024    4      0 
9000  9000 0xff 0xff
           flash         33     6   256    0 yes     32768  128    256 
4500  4500 0xff 0xff
           lock           0     0     0    0 no          1    0      0 
9000  9000 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0 
9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0 
9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0 
9000  9000 0x00 0x00
           signature      0     0     0    0 no          3    0      0 
0     0 0x00 0x00
           calibration    0     0     0    0 no          1    0      0 
0     0 0x00 0x00

         Programmer Type : STK500V2
         Description     : Atmel STK500
         Programmer Model: STK500
         Hardware Version: 10
         Firmware Version Master : 2.10
avrdude: stk500v2_command(): command failed
avrdude: stk500v2_getparm(): failed to get parameter 0x9a
         Topcard         : Unknown
         Vtarget         : 5.0 V
avrdude: stk500v2_command(): command failed
avrdude: stk500v2_getparm(): failed to get parameter 0x95
avrdude: stk500v2_command(): command failed
avrdude: stk500v2_getparm(): failed to get parameter 0x96
avrdude: stk500v2_command(): command failed
avrdude: stk500v2_getparm(): failed to get parameter 0x97
         SCK period      : 17.4 us
         Varef           : 14.8 V
         Oscillator      : 52.663 kHz

avrdude: stk500v2_command(): command failed
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

Mit der -B, -b und -i Option habe ich auch schon rumprobiert... ohne 
Erfolg...

Ich denke auch nicht, dass er kaputt ist, denn der alte Code, den ich 
vorher drauf geflasht hab, läuft noch. Ich Pin wechselt noch den 
Zustand, nur eben deutlich langsamer...

Die ganzen anderen Threads und Webseiten, die ich gefunden habe, die ein 
ähnliches Problem beschreiben, kommen entweder zu keiner Lösung oder 
behandeln dann doch ein anderes Problem...

Jetzt meine Frage:
Weiß jemand, wie ich das wieder hin bekomme?

Danke schonmal,
Tobias

[m.n. (Gast)]

Setz mal den Programmiertakt auf <= 32 kHz.

[Tobias E. (tobinator)]

hab ich schon versucht, funktioniert aber nicht...
ich hab im Atmel Studio die niedrigst mögliche Frequenz eingestellt, 
aber immer noch die gleiche Fehlermeldung

[S. Landolt (Gast)]

> ich hab im Atmel Studio die niedrigst mögliche Frequenz eingestellt,

Tja, noch niedriger...
Falls nämlich die CKDIV8-Fuse programmiert sein sollte, muss man unter 4 
kHz = 128 kHz /8 /4 kommen.

[Tobias E. (tobinator)]

Also bis 1,205 kHz kann ich in Atmel Studio einstellen, aber das 
funktioniert nicht.

Gibt es noch irgendeine Möglichkeit, die Frequenz noch weiter runter zu 
bekommen?

[m.n. (Gast)]

Tobias E. schrieb:
> Ich habe "Int. 128kHz RC
> Osc." eingestellt.

Vielleicht hast Du aus Versehen auf ext. Takt eingestellt. Testweise 
kannst Du ein Taktsignal an XTAL1 anlegen und erneut probieren.

[S. Landolt (Gast)]

Merkwürdig, die 1.2 kHz müssen reichen. Sicher, dass der 128 kHz 
Oszillator eingestellt wurde? Versuchsweise mal einen externen Takt an 
XTAL1 anlegen.

[HildeK (Gast)]

Geht mit der ganz langsamen Geschwindigkeit auch das Ändern der Taktfuse 
nicht?
Probier ggf. vorher mal "Erase All".

Ansonsten: HV-Programmierung.

[HildeK (Gast)]

Nachtrag: ich meine mich zu erinnern, dass ich in so einem Fall mit 4kHz 
Programmiertakt die Fuse wieder zurückstellen konnte.

[Tobias E. (tobinator)]

Ja, ich bin mir schon ziemlich sicher, dass ich "Int. 128kHz RC Osc.; 
Start-up time: 6 CK + 64 ms INTRCOSC_128KHZ_6CK_64MS" eingestellt habe.

Einen externen Takt kann ich im Moment nicht anlegen, weil ich gerade 
nichts da hab. Aber wie gesagt, ein Pin macht ja was...

Ich kann ja mal schreiben, was meiner Meinung nach relevant sein könnte:

Also das, was gerade darauf läuft, sendet auf UART einen Buchstaben.
F_CPU steht auf 3120000UL
Baudrate steht auf 100UL

Ein Bit dauer ca. 2,19s.

Hilft das irgendwie weiter?

[Wolfgang (Gast)]

Tobias E. schrieb:
> Baudrate steht auf 100UL

Was meinst du damit?
Ist das die Baudrate oder soll das der Wert im UBRR sein?

[S. Landolt (Gast)]

So ganz ungefähr komme ich da doch auf einen Systemtakt von 16 kHz = 128 
kHz /8:  3120000 /2.19 *0.01 = 14.25 kHz, es müssten dann die 1.2 kHz 
Programmiertakt reichen.

[Tobias E. (Gast)]

Ändern der Fuses geht leider auch nicht und erase all auch nicht...

Ich werde mir mal ein andere Interface besorgen und es damit 
probieren... und die Verkabelung werde ich auch mal checken.
Wäre zwar komisch, wenn da zufällig beim setzen der Fuse was kaputt 
gegangen ist, aber manchmal gibt's ja auch komische Zufälle...

[Tobias E. (Gast)]

Wolfgang schrieb:
> Tobias E. schrieb:
> Baudrate steht auf 100UL
>
> Was meinst du damit? Ist das die Baudrate oder soll das der Wert im UBRR
> sein?

Eigentlich baudrate, dachte ich... ich kontrolliere es mal, wenn ich 
gleich wieder zu Hause bin

[Stefan F. (Gast)]

Welchen Programmieradapter verwendest du? Ist es das originale STK500 
Board, oder etwas anderes?

[Tobias E. (Gast)]

Bin gerade unterwegs, deswegen kann ich nicht genau nachgucken, aber es 
müsste der hier in einer älteren Version sein

https://www.diamex.de/dxshop/USB-ISP-Programmer-fuer-Atmel-AVR-Rev2

So ein diamex-Teil, hab ich mir vor Jahren mal bei reichelt bestellt...
Meiner hat nur den 10-poligen Anschuss

[Marc V. (Firma: Vescomp) (logarithmus)]

Tobias E. schrieb:
> Ja, ich bin mir schon ziemlich sicher, dass ich "Int. 128kHz RC Osc.;
> Start-up time: 6 CK + 64 ms INTRCOSC_128KHZ_6CK_64MS" eingestellt habe.

 Man soll nicht mit Fuses rumspielen, ohne genau zu wissen was man 
tut...

[STK500-Besitzer (Gast)]

Tobias E. schrieb:
> https://www.diamex.de/dxshop/USB-ISP-Programmer-fuer-Atmel-AVR-Rev2
>
> So ein diamex-Teil, hab ich mir vor Jahren mal bei reichelt bestellt...
> Meiner hat nur den 10-poligen Anschuss

Damit wirst du nichts, wenn du den Controller entfusen willst. Dazu 
brauchst du einen Programmer, der HV-Parallel-Programming beherrscht.

[Tobias E. (tobinator)]

Marc V. schrieb:
> Man soll nicht mit Fuses rumspielen, ohne genau zu wissen was man
> tut...

Danke für den Hinweis, hilft mir jetzt aber nicht weiter...
Kannst du mir sagen, was genau das Problem ist? Er macht ja scheinbar 
was, nur halt sehr langsam...


STK500-Besitzer schrieb:
> Damit wirst du nichts, wenn du den Controller entfusen willst. Dazu
> brauchst du einen Programmer, der HV-Parallel-Programming beherrscht.

Da bekomme ich hoffentlich demnächst einen (Atmel ICE)...

Aber sind die fuses wirklich so falsch gesetzt? Da er noch etwas macht, 
dachte ich eigentlich, dass man ihn schon noch retten kann.
Ich hab eigentlich gehofft, irgendjemand sagt mir einfach eine Option, 
die ich umstellen muss und ...Zack... gehts wieder...

Mal noch kurz was zu meinen Erfahrungen:
Ich mach das alles nur hobbymäßig. Ich nutze das alles nicht 
professionell und hab auch keine High-Tech-Geräte zur Verfügung. Mir 
geht eigentlich nur ums lernen, basteln und Erfahrung sammeln.

[Marc V. (Firma: Vescomp) (logarithmus)]

Tobias E. schrieb:
> Aber sind die fuses wirklich so falsch gesetzt?

 Ja, das sind sie.

> Da er noch etwas macht,
> dachte ich eigentlich, dass man ihn schon noch retten kann.
> Kannst du mir sagen, was genau das Problem ist? Er macht ja scheinbar
> was, nur halt sehr langsam...

 Er macht schon was er soll, nur halt 500 Mal langsamer.


> Ich hab eigentlich gehofft, irgendjemand sagt mir einfach eine Option,
> die ich umstellen muss und ...Zack... gehts wieder...

 Wie willst du das machen wenn dein m324 nicht mehr über ISP
 ansprechbar ist, selbst mit (angeblichen) 1,2KHz ?


> Einen externen Takt kann ich im Moment nicht anlegen, weil ich gerade
> nichts da hab. Aber wie gesagt, ein Pin macht ja was...

 Leider geht es ohne externen Takt oder HV nicht...

[Stefan F. (Gast)]

Leider steht in der Bedienungsanleitung nicht drin, welche 
Taktfrequenzen der Programmieradapter unterstützt.

Interessant finde ich, dass in der Anleitung von einem anderen Diamex 
Programmer hingegen eine Tabelle mit den unterstützten Taktraten drin 
ist.

Ich habe auch noch einen Programmer von einer anderem Marke in der 
Bastelkiste, der in genau der gleichen Situation nicht mehr 
funktionierte. Aber der Hersteller stellte wenige Wochen nach meiner 
Reklamation ein entsprechendes Firmware-Upgrade bereit.

Vielleicht ist Diamex ebenso hilfsbereit.

[go ARM (Gast)]

Mal wieder so ne alte Kamelle verfused. Schmeiss Weg die Sch... und nimm 
was richtiges. Die Dinger sind überholt. Verschwenden keine Zeit mehr 
...

[STK500-Besitzer (Gast)]

go ARM schrieb im Beitrag #5381293:
> Mal wieder so ne alte Kamelle verfused. Schmeiss Weg die Sch... und nimm
> was richtiges. Die Dinger sind überholt. Verschwenden keine Zeit mehr
> ...

Wenn du dich dann um die damit verbundenen Probleme kümmerst!

[STK500-Besitzer (Gast)]

Tobias E. schrieb:
> Da bekomme ich hoffentlich demnächst einen (Atmel ICE)...

Und was soll dir das bei verfusten Controllern helfen?

[Tobias E. (Gast)]

Also so wie ich das bisher verstanden hab, würde er bei richtig verfused 
gar nichts mehr machen. Das ist ja nicht der Fall. Er läuft nur sehr 
langsam...

Ich hab gerade so die Hoffnung, das mein Programmieradapter einfach nur 
sagt, er kann 1,2 kHz, kann es aber tatsächlich gar nicht. Wenn ich 
jetzt einen anderen nehme, der wirklich 1,2 kHz kann, dann geht's 
vielleicht. Das würde ja dann auch zu der Berechnung von S Landolt 
passen.

Das er läuft, gibt mir die Hoffnung, das ich es noch mit einem anderen 
Programmieradapter hinkriegen kann...

[Maxim B. (max182)]

Tobias E. schrieb:
> und hab auch keine High-Tech-Geräte zur Verfügung.

Ein Stück 74HC00, ein Quarz, ein Widerstand und zwei Kondensatoren.

[S. Landolt (Gast)]

> Mir geht eigentlich nur ums lernen, basteln und Erfahrung sammeln.

Nur zu!
Ein paar Kabel, ein Taster mit RC-Glied, und damit das Fuse-Low-Byte auf 
den Werkswert von 0x62 zurücksetzen; die Anleitung steht im Datenblatt 
unter 'Serial downloading' und 'Serial Programming Instruction set'. 
Verlangt ein oder zwei Stunden Zeit, ein hohes Maß an Disziplin und eine 
recht hohe Frustrationsschwelle, ist aber machbar.

[Tobias E. (tobinator)]

S. Landolt schrieb:
>> Mir geht eigentlich nur ums lernen, basteln und Erfahrung
> sammeln.
>
> Nur zu!
> Ein paar Kabel, ein Taster mit RC-Glied, und damit das Fuse-Low-Byte auf
> den Werkswert von 0x62 zurücksetzen; die Anleitung steht im Datenblatt
> unter 'Serial downloading' und 'Serial Programming Instruction set'.
> Verlangt ein oder zwei Stunden Zeit, ein hohes Maß an Disziplin und eine
> recht hohe Frustrationsschwelle, ist aber machbar.

Danke, danke, danke
Ich fühle mich grade wie der krasseste Hacker der Welt :D

Es geht wieder.

Mein Vorgehen:
Ich habe mir ein Analog Discovery2 besorgt (Logic-Analyzer, mit dem man 
auch SPI-Daten senden kann) und damit dann mit 200 Hz Daten gesendet:

function initialize(){
    Start();
    Write(8, 0xAC, 0x53, 0x00, 0x00);  // Programming Mode
    Write(8, 0x30, 0x00, 0x00);        // Device ID
    var id1 = Read(8, 1);
    Write(8, 0x30, 0x00, 0x01);
    var id2 = Read(8, 1);
    Write(8, 0x30, 0x00, 0x02);
    var id3 = Read(8, 1);

    Write(8, 0x50, 0x00, 0x00);        // Fuse lesen
    var fuse_alt = Read(8, 1);
    
    Write(8,0xAC, 0xA0, 0x00, 0x62);   // Fuse setzen

    Write(8, 0x50, 0x00, 0x00);        // Fuse lesen
    var fuse_neu = Read(8, 1);

    Stop();
    
    return "Device ID:" + id1 + " " + id2 + " " + id3 + ", Fuse: " + fuse_alt + "/" + fuse_neu;
}
function loop(){
    // Process called for specified number of times and rate.
    // Like to collect, decode and store sensor data.
    // Use only static data trasnfer calls!
    return true;
}
function finish(){
   // Process called at the end.
   // Like to suspend the device.
   return "done";
}

Und jetzt kann Atmel-Studio auch wieder flashen.

Danke nochmal für eure Hilfe.

Achja, noch eine Erkenntnis, die ich gewonnen habe, die vielleicht noch 
für jemanden anderes interessant sein könnte:

Entweder ist die Option -B in AVRdude nicht das, was ich denke, oder 
mein Programmer macht komische Sachen. Ich habe einige -B-Optionen 
eingestellt und dann die SPI-Clock gemessen. Die Zeiten sind jeweils 
eine High- und eine Low-Phase. Das, was nach meinem Verständnis eine 
Periode sein sollte...
Hier die Ergebnisse:

SCK Period [µs] (-B-Option)  Gemessene Periode [µs]    Gemessene Frequenz [kHz]
10                           1,98                      505
20                           3,99                      251
50                           10,32                     96,9
100                          19,71                     50,7
150                          38,34                     26,1
200                          38,22                     26,2
300                          94,64                     10,6
400                          94,64                     10,6
500                          94,64                     10,6
600                          160,1                     6,24

Und höher geht es dann auch nicht.
Also ist die höchste Frequenz, die dieses Interface kann, wohl 6,24kHz, 
was in meinem Fall wohl zu hoch war.

[Stefan F. (Gast)]

> Ich habe mir ein Analog Discovery2 besorgt (Logic-Analyzer, mit dem man
> auch SPI-Daten senden kann) und damit dann mit 200 Hz Daten gesendet

Wow! Dafür wäre ich zu faul gewesen.

> Entweder ist die Option -B in AVRdude nicht das, was ich denke,
> oder mein Programmer macht komische Sachen.

Manche Programmer unterstützen die Option komplett, manche nur teilweise 
und manche gar nicht.

[S. Landolt (Gast)]

an Tobias E.:

Wäre nicht so schlimm gewesen, wie ich es in Erinnerung hatte; damals 
war es ein kleines Programm, hier geht es ja nur um das Fuse-Low-Byte, 
also 2 Sequenzen, d.h. 64 Bits von Hand eingeben, das ist durchaus noch 
akzeptabel. Und ja, ich hatte es noch gestern abend ausprobiert.

[c-hater (Gast)]

Stefan U. schrieb:

> Manche Programmer unterstützen die Option komplett, manche nur teilweise
> und manche gar nicht.

Garnicht ist mir noch nicht untergekommen. Was mir allerdings vielfach 
untergekommen ist: Es funktioniert nur mit einem teils sehr deutlichen 
Versatz gegenüber dem STK500-Original. Da der übermittelte Wert des 
Protokolls ein Reziprokwert der Frequenz/Bitrate ist, kann man den 
Versatz aber auch nicht einmal in einer einfachen, DAU-tauglichen 
Beschreibung ausdrücken.

Dazu kommen dann einige Beschränkungen nach oben und/oder unten bei 
bestimmten Programmern. Oft ist schon sehr einfach zu klären, wo diese 
herrühren: eindeutig völlig unfähige Programmierer, denen offensichtlich 
nicht mal des primitive Konzept des Reziproks klar war, denen aber wohl 
die Takt-Abweichungen zum Original irgendwie auf die Stulle geschmiert 
wurde. Die haben dann ganz offensichtlich exakt genau das getan, was man 
in dieser Fakten-Konstellation von Leuten dieser Kompetenzklasse 
erwarten muss...

Man kann dann sehr schön sehen, welche Rate sie als "Normwert" 
angenommen haben und wie sie darauf basierend die Grenzen festgelegt 
haben. Sehr lustig, das, wenn's nicht so traurig wäre...

[Stefan F. (Gast)]

>> Manche Programmer unterstützen die Option komplett, manche nur teilweise
>> und manche gar nicht.

> Garnicht ist mir noch nicht untergekommen.

Ich kann zwei Beispiele nennen:
Der ICprog-AVR 2.0 und meine chinesischen USBASP clones. Beide Typen 
knobeln die Übertragungsrate automatisch aus. Manuelle Vorgaben 
ignorieren sie.