ATMEGA88V reagiert nach make programm nicht mehr

[Thomas F. (Gast)]

Hallo,

ich dachte ich frage jetzt mal bei euch nach, bevor ich meinen zweiten 
Controller zerschieße.

Was habe ich getan?
-> Mir einen ATMEGA88V gekauft, da dieser wegen der 1,8V einen ATMEGA8 
ersetzen soll.
-> die Fuses mit meinem PC ausgelesen.

avrdude -p m88 -c avrispv2 -P /dev/ttyACM0 -v

avrdude: Device signature = 0x1e930a (probably m88)
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as F9

avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as F9
avrdude: safemode: Fuses OK (E:F9, H:DF, L:62)

avrdude done.  Thank you.

So jetzt war ich happy und habe mir die Fuses erst mal mit einem Fuse 
Calc angeschaut. Dann habe ich das so Interpretiert als wäre er auf 
internal Oszilator 1Mhz konfiguriert.

... Ich dachte mir okay da spielen wir mal nicht mit den Fuses ...

Ich habe im makefile von 2Mhz auf 1Mhz geändert und dann

make clean
make
make program

gemacht.

Darauf hin hat mir avrdude erzählt, dass es sich nicht um einen atmega8 
handelt.
Ich habe im Makefile von atmega8 auf atmega88 geändert und wieder

make program
getippt.

Der Code wurde in den Controller geladen und dann tat sich nichts. Also 
dachte ich mir einmal Strom aus / an (5V) dann sollte er neu booten. 
Aber die Led die eigentlich blinken sollte reagierte nicht.

Also habe ich versucht wieder die Fuses mit dem Kommando von oben zu 
lesen und bekomme keinen Connect mehr zum ATMEGA88V

Das Programm enthät Timer und Interrupts. Ich habe erst nachher gelesen, 
dass man das von ATMEGA8 auf 88 portieren muss aber deswegen sollte doch 
nicht gleich die ISP Schnittstelle nicht mehr reagieren oder?

Ich wollte erst mal euch fragen, was ich jetzt beachten sollte, bevor 
ich den zweiten ATMEGA88V in den Sockel setze und dieser auch kaputt 
geht.

Meiner Meinung nach hätte da nichts schief gehen sollen, da ich die 
Fuses ja nie verändert habe. Kann der Binary Code den ATMEGA88V so 
zerstört haben, da er für ATMEGA8 kompiliert war? Oder sollte der ISP 
trotzdem noch funktionieren?.

Habt ihr noch Tipps, was ich noch ausprobieren könnte, bevor der 
ATMEGA88V entsorgt wird? Beim zweiten kann ich die Fuses lesen, also 
liegt es nicht an der Schaltung. Das geht auch mehrfach und auch nach 
dem ich den Strom aus und wieder ein geschalten habe.

[EAF (Gast)]

Thomas F. schrieb:
> da ich die Fuses ja nie verändert habe.
Das glaube ich dir nicht.

[EAF (Gast)]

Thomas F. schrieb:
> und dieser auch kaputt geht.
Wenn nix anderes mehr geht, wirds ein HV Programmer doch noch richten 
können

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

Was genau ist denn die Kommandozeile, die dein

make program

mit dem AVRDUDE ausführt?

[Axel S. (a-za-z0-9)]

Thomas F. schrieb:
> Ich habe im Makefile von atmega8 auf atmega88 geändert und wieder
>
> make program
> getippt.
>
> Der Code wurde in den Controller geladen und dann tat sich nichts.

Na, dann ist das wohl der Fehler. Dein unbekanntes (uns jedenfalls) 
Makefile hat irgendwas unbekanntes ausgeführt. Vermutlich Code auf den 
µC geladen (natürlich ebenso unbekannt). Vielleicht aber auch die Fuse 
auf - für den ATmega8 gültige - neue Werte gesetzt. Warum sollte das 
auch für deinen ATMega88 funktionieren?

[Stefan F. (Gast)]

Weil die Frage hier öfter kommt habe ich Tipps dazu gesammelt: 
http://stefanfrings.de/avr_verfused/index.html

In deinem Fall hilft vielleicht:
> Und dann gibt es noch einen letzten Rettungsanker:
> Den Reset Pin fest mit GND verbinden  ...

[Holger L. (max5v)]

Thomas F. schrieb:
> Habt ihr noch Tipps, was ich noch ausprobieren könnte, bevor der
> ATMEGA88V entsorgt wird?
Gemäß dem Fall das in der Makefile die Standardeinstellungen der Fuses 
für den ATmega8 eingetragen waren, kann es sein das der nun auf External 
Clock steht. SPI sollte noch aktiv sein.
Es wäre durchaus einen Versuch wert an PB6 XTAL1 ein Clock Signal 
anzulegen bevor der in der Tonne landet.
Zum Beispiel mit dem zweitem ATmega. Eigentlich müßte man nur die 
(leider) Fuseeinstellung "Clock output on PORTB0; [CKOUT=0]" aktivieren.

[Martin V. (oldmax)]

Hi
Das ist mir im Anfang auch passiert, das der externe Taktgeber aktiviert 
und die Quarzbeschaltung fehlerhaft war. Da hilft mit einem TTL 
Logikbaustein ein simpler Taktgeber. Selbst ein paar hundert Hz reichen, 
um interne Fuses wieder zu richten.
Gruß oldmax

[Stefan F. (Gast)]

Martin V. schrieb:
> Selbst ein paar hundert Hz reichen,
> um interne Fuses wieder zu richten.

Nicht jeder Programmieradapter kann entsprechend langsam übertragen. Mit 
8 MHz ist man auf der sicheren Seite.

[Martin V. (oldmax)]

Thomas F. schrieb:
> Meiner Meinung nach hätte da nichts schief gehen sollen, da ich die
> Fuses ja nie verändert habe. Kann der Binary Code den ATMEGA88V so
> zerstört haben, da er für ATMEGA8 kompiliert war? Oder sollte der ISP
> trotzdem noch funktionieren?.

Hi
Ich bin überzeugt, das ein Programm einen Controller nicht zerstören 
kann, aber eine ganz andere Funktion bewirkt. Auch die ISP Frequenz 
könnte zu hoch sein und du eben nur einen leeren Controller vorliegen 
hast. Wenn vorher 16 MHz und jetzt nur 1 MHz könnte das schon sein. 
Bevor du ihn in die Tonne haust, Check das erst Mal.
Gruß oldmax

[Thomas (Gast)]

Das Programm hatte dafor 2Mhz gesetzt. Ich habe mir jetzt mal einen HV 
Fuse Retter mit einem Arduino gebastelt und werde mal sehen ob ich die 
Fuses damit auf default setzen kann.

Das Programm sollte ja keine Auswirkungen auf den ISP haben oder? Da 
dürfte nur ein Problem mit den Fuses oder der defekt des Controllers 
Auswirkungen haben.

Zum Glück kann ich ja nichts mehr kaputt machen 😅 der Controller sitzt 
in einem Art Texttool Sockel auf Lego

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

Du hast die Frage immer noch nicht beantwortet, welche Kommandozeile 
dein "make program" nun genau ausgeführt hat.

Die Vermutung liegt immer noch nahe, dass es keiner HV-Programmierung, 
sondern nur eines externen Takts bedurft hätte.

[Max M. (Gast)]

Thomas F. schrieb:
> von 2Mhz auf 1Mhz geändert

OSC verfused.
Die MCU würde schon noch laufen, bekommt aber keinen Takt mehr.
Für sowas habe ich einen 1Mhz Taktoszillator mit ttl Ausgang rumliegen 
mit dem ich den AVR zwangsweise takte bis ich die fuses neu gesetzt 
habe.

[EAF (Gast)]

Thomas schrieb:
> Das Programm hatte dafor 2Mhz gesetzt.
Die Aussage kann/muss falsch sein, da sie die Fuses nicht in die 
Rechnung einbezieht.

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

Beim ATmega88 kann man 2 MHz gar nicht per Fuse einstellen, nur 1 oder 
8.

[EAF (Gast)]

Jörg W. schrieb:
> Beim ATmega88 kann man 2 MHz gar nicht per Fuse einstellen,

16er Quarz und DIV8

[Thomas (Gast)]

Hallo,
Ich bin leider gerade unterwegs aber versuche die Fragen mal zu 
beantworten.

Die genauen Kommandos schaue ich nachher in der Makefile nach.

Die Variable F_CPU war auf 2Mhz gesetzt. Sollte jedoch ja nur das 
Programm beeinflussen und nicht die SPI Schnittstelle.

@Jörg der Tipp ist gut vielleicht kann ich ja auch mit dem Arduino einen 
1MHz tackt erzeugen und ihn so wieder beleben ohne HV Programming.

Ich melde mich sobald ich neue Erkenntnisse habe

[Stefan F. (Gast)]

Thomas schrieb:
> Das Programm sollte ja keine Auswirkungen auf den ISP haben oder?

Wenn du meine oben empfohlene Webseite gelesen hättest, wüsstest du, 
dass ich diese Frage mit einem klaren NEIN beantwortet habe. Zur 
Bedeutung der F_CPU Definition (nicht Variable!) habe ich da auch etwas 
geschrieben.

Nochmal der Link: http://stefanfrings.de/avr_verfused/index.html

[Thomas F. (Gast)]

So jetzt komme ich dazu die Beiträge in Ruhe zu sondieren und mal 
Schritt für Schritt aus zu testen.

Als erstes habe ich den Link über AVR Verfused jetzt gelesen. Danke für 
den tollen Beitrag, dadurch bin ich schon mal schlauer geworden.

Auch das Makefile habe ich genau unter die Lupe genommen.
folgendes wird ausgeführt beim make programm

avrdude -p atmega8 -P /dev/ttyACM0 -c stk500v2 -U flash:w:$(TARGET).hex
-> Hinweis, dass es keine atmega8 cpu ist

avrdude -p atmega88 -P /dev/ttyACM0 -c stk500v2 -U flash:w:$(TARGET).hex
-> erfolgreicher Upload.

Im Make File stand zuerst
F_CPU =  2000000
was ich dann für den ATMEGA88V auf
F_CPU =  1000000
geändert habe


1. Test ist jetzt ich ziehe den Reset mal fest auf GND und versuche die 
Fuses zu lesen.
--> Das alleine hat beim lesen erst mal nicht geholfen. Ich habe dann -B 
2000 angefügt und schon at er die Fuses gelesen.
Zu meinem Erstauen wurden die default Fues 62 DF ausgegeben.

Ich habe jetzt im Quellcode und Makefile die F_CPU nochmal kontrolliert.
beide bei F_CPU=1000000
dann
make clean
make
make programm

und sieh da jetzt läuft es :-). Ich freue mich so und vielen Dank für 
eure Unterstützung.

Jetzt werde ich mir gleich mal ansehen, was ich bei der Portierung von 
ATMEGA8 auf ATMEGA88V beachten muss.

[Stefan F. (Gast)]

Thomas F. schrieb:
> und sieh da jetzt läuft es

Das freut mich.

[Thomas F. (Gast)]

Eine Frage hätte ich da noch. ...

Wenn ich das richtig sehe, habe ich beim ATMEGA88V die Wahl zwischen 8 
und 1Mhz aber ich kann mit Boardmitteln (interner Oszi) nicht 2Mhz bei 
1,8V einstellen. Oder liege ich da falsch? Am XTAL Anschluss hängt schon 
ein Uhrenquarz, also ist der belegt.

Bei den älteren Controllern konnte man ja noch zwischen verschiedenen 
Takten über die Fuses wählen.

Mit 1Mhz bekomme ich keine Baud von 9600 gebacken und müsste mein BT 
Modul in der Baud ändern. So habe ich das zumindest einer Atmel Baud 
Tabelle entnommen.


Da hilft wohl auch das
https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART

USE_2X Flag nicht oder? << Diess Flag ist mir noch ein Rätsel.

[Thomas F. (Gast)]

Thomas F. schrieb:
> Eine Frage hätte ich da noch. ...
>
> Wenn ich das richtig sehe, habe ich beim ATMEGA88V die Wahl zwischen 8
> und 1Mhz aber ich kann mit Boardmitteln (interner Oszi) nicht 2Mhz bei
> 1,8V einstellen. Oder liege ich da falsch? Am XTAL Anschluss hängt schon
> ein Uhrenquarz, also ist der belegt.
>
> Bei den älteren Controllern konnte man ja noch zwischen verschiedenen
> Takten über die Fuses wählen.
>
> Mit 1Mhz bekomme ich keine Baud von 9600 gebacken und müsste mein BT
> Modul in der Baud ändern. So habe ich das zumindest einer Atmel Baud
> Tabelle entnommen.
>
>
> Da hilft wohl auch das
> https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART
>
> USE_2X Flag nicht oder? << Diess Flag ist mir noch ein Rätsel.

Verstehe ich das korrekt, dass ich mit dem U2X Modus 0,2 Fehlerquote 
erreichen würde?

https://alexandria.atmel.com/pr/GUID-ED37252C-1496-4275-BAEF-5152050ED2C2-en-US-2/index.html?GUID-65A53416-8DE2-468E-99CF-09F480AEF734

Und somit das ganze mit 1Mhz wieder funktionieren würde.

[EAF (Gast)]

Thomas F. schrieb:
> Bei den älteren Controllern konnte man ja noch zwischen verschiedenen
> Takten über die Fuses wählen.
Nööö.... eher nicht.

Du kannst zur Laufzeit den Prescaler ändern.
Vermutlich kann er auch DIV4 (das Datenblatt gibt Auskunft)

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

Thomas F. schrieb:
> Oder liege ich da falsch?

Liegst du.

Die CKDIV8-Fuse bei den halbwegs modernen AVRs ist weiter nichts als 
eine Voreinstellung des clock prescalers auf 1:8. Der lässt sich aber 
(anders als bei den ganz alten AVRs) halt zur Laufzeit auf beliebige 
2^N-Werte zwischen 1:1 und 1:256 umschalten.

Im Gegensatz dazu war das beim ATmega8 nicht zur Laufzeit möglich, 
sondern man konnte dort nur per Fuse zwischen vier verschiedenen 
RC-Oszillatoren (oder diversen anderen Takten) wählen.

[Thomas F. (Gast)]

Oh super, das ist gut zu wissen.

Mit UART bin ich auch weiter gekommen die U2X hat geholfen :-)

Damit könnte man das Thema hier abschließen. Muss ich das Thema 
irgendwie auf "erledigt" setzen?

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

Thomas F. schrieb:
> Muss ich das Thema irgendwie auf "erledigt" setzen?

Nö. Ist halt alles gesagt, und der Thread verschwindet in der 
Versenkung, außer dass er halt durch die Suchmaschinen noch gefunden 
wird – falls mal jemand ein ähnliches Problem hat, kann er/sie es 
nachlesen.