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.
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
1
make clean
2
make
3
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.
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?
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 ...
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.
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
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.
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
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
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.
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.
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
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
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.
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. 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.
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)
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.
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?
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.
