Fuse Bits ATMega168

Hallo,

ich bin auch Neuling in der Prozessor-Programmierung.

Ich hab den ASURO mit der SUMO-Erweiterung und wollte den mit einem ATMega168 zum laufen bringen. Als ich merkte, dass die Timer "nicht stimmen" und ich keine Kommunikaton über die IR-Schnittstelle hinbekommen, bin ich - wieder mal - auf die Fuse-Bits gestossen.

Der ATMega168 läuft wohl noch mit den internen 1MHz. Da ich gehört hab, dass man mit den Fuse-Bits viel falsch machen kann, suche ich hier Hilfe. Welche Werkzeug nimmt man? avrdude? AVR-Studio?

Für avrdude benötige ich wohl drei korrekte Hexzahlen.
Im AVR-Studio 4 bin ich auch nicht weit gekommen. Ich finde dort acht Möglichkeiten für einen ext. Crystal. Osc. 8Mhz, wo mir die nachfolgenden Parameter nichts sagen.

Hallo esieg,

willkommen im Forum

Zitat:

---

Zitat von esieg

... ATMega168 zum laufen bringen ... gehört hab, dass man mit den Fuse-Bits viel falsch machen kann ...

---

Genau so ist es. Deshalb gibt es einen sehr praktischen Fusebit-Calculator. Sprich: eine ausgefuchste Einstell-Tabelle.
http://www.engbedded.com/fusecalc/

Ich weiß nicht, wie schnell der Quarz für Deinen mega168 läuft - aber ich denke Du wirst nur ein einziges Häkchen setzen - das bei SPIEN. Denk daran, dass zur besseren Unverständlichkeit Atmel immer von einer "1" spricht, wenn dieses "Häkchen" nicht gesetzt ist - schau Dir also den unteren Teil im Calculator an - darin ist also nur dieses SPIEN mit Haken versehen. Dies alles ohne Gewähr ! Da Du auch nicht schreibst, wie Du den m168 flasht, kann ich zum Fusebitsetzen nichts sagen. Bei mir geht das mit einem STK500-Clone direkt aus dem AVRSTudio - und das ist relativ übersichtlich.

Ich emphele http://www.engbedded.com/fusecalc/ für eine Lösung.

lg,

Ed

Vielen Dank, die Herren. Das ging ja schneller, als die Polizei erlaubt.

Über den Calculator bin ich gestern nacht auch schon "gestolpert", war mir aber auch bei dem nicht sicher.

Ich programmiere den ATMega168 über ISP, Protokoll STK500v2 mit einem USB-Programmer (Diamex DX USB). Spannung nehme ich dabei 5V vom USB-Programmer. Nach einigen Anlaufschwierigkeiten (wegen der Switches auf dem Programmer) funktioniert das eigentlich ganz gut. Mit dem AVR-Studio hab ich da schon mehrfach geflasht, mit avrdude "gelesen".

Mit diesen Hinweisen: gibt es noch etwas zu beachten bei den ganzen Bits?

Hallo,

vergessen hat ich noch den Quarz. Wenn ich nicht falsch liege (auf die Schnelle: http://www.asurowiki.de/pmwiki/pmwik...Main/Prozessor) taktet der 8MHz.

Zurück zu fusecal: Wenn ich die "Feature configuration" nehme ...
habe ich aber beim fusecal allein acht Möglichkeiten für den externen Quarz:

Alle Kombinationen CKSEL 1110 SUT 00 bis CKSEL 1111 SUT 11.

Weiter:
- Divide clock by 8 internally; [CKDIV8=0] ?
- Clock output on PORTB0; [CKOUT=0] ?

Was nimmt man hier? Fasst man das an oder lässt man das?

Wie schreibt man überhaupt? Mit AVR-Studio erst die FUSE-Bits lesen, dann den Wert für Clock ändern und wieder schreiben?
Oder lieber mit avrdude die kompletten drei Bytes setzen?

Zitat:

---

Zitat von oberallgeier heute um 09:08

... ich denke Du wirst nur ein einziges Häkchen setzen - das bei SPIEN ...

---

Aha, bezog sich auf den Abschnitt

Manual fuse bits configuration

Für mich (zum mitschreiben)

• CKSEL = 1111
  SUT = 11

Dumme Frage des Laien am Rande:
CKDIV8=0
würde bei externem Takt von 8MHz den Prozessor intern mit einem MHz takten ? (Ich geb's ja zu, bin noch nicht dazu gekommen, mich in diverse Datenblätter zu vertiefen. Das Meiste hab ich bislang aus den Büchern "Mehr Spass mit dem Asuro")

Vielen Dank für die Hilfe. Ich werde es heute Abend ausprobieren - wohl am besten mit avrdude.

Ich verwende folgende Einstellungen für den Asuro mit ATmega168 und 8MHz Quarz.
Low: FF, High: DD, Extended: F9
Das enspricht folgenden Einstellungen:
CKSEL = 1111 (8MHz ext. Crystal Osc 8.0-Mhz)
SUT = 11 (Startup Delay maximum)
BODLEVEL 101 (2,7V)
SPIEN = 0 (enable, kann man nicht durch ISP ändern)
BOOTSZ = 00 (1024words, ist egal, solange kein Bootloader verwendet wird)

alle anderen Fuses auf 1, nicht programmiert, kein Haken

tja, ich hab ihn wohl geschrottet:

• - ich hab alle drei Bytes in einer Zeile übergeben (avrdude -cstk500v2 -pm168 -Pcom4 -U lfuse:w:0xff:m -U hfuse:w:0xdd:m -U efuse:w:0xf9:m)
  - dann hat avrdude Eines nach dem Anderen mit viel Protokoll geschrieben und verifiziert
  - dann meldete das Programm einen Fehler im Verify des extfuse
  - dann hab ich wohl erschrocken dem Falschen zugestimmt
  - der USB-Programmer verschwand in einer Endlosschleife (LED signalisierte Zugriff auf den Controller, jedoch keinerlei Rückmeldung mehr)
  - in meiner Verzweiflung hab ich ihn vom USB-Kabel getrennt
  - und nun hab ich wieder meinen schönen Fehler "stk500v2_command(): command failed" - auch bei einem ATMega8, der definitiv "noch tut" und auch bei einem ASURO 16K (soll ja wohl auch ein ATMega168 sein)

Und darin sind sich der avrdude und AVR-Studio konsequent einig. Ich weiss nun nicht mal genau, was alles platt ist:

• der ATMega168
  der Programmer
  beide

und habe keinen Plan, wie ich das herausbekomme ...

Das ist ja übel. Ich habe sie Einstellungen nochmals verifiziert und kann keinen Fehler feststellen, der einem vom Prozessor aussperrt. Außer man hat keinen externen Quarz Oszillator dran.

Die Fehlermeldung beim verify ist allerdings richtig, das ist eine avrdude Macke. Es gibt eigentlich nur 3 extended Bits beim mega168. Die oberen 5 Bits sind irrelevant. Man hätte auch 0x01 programmieren können, dann gäbe es keine Fehlermeldung.

Funktioniert denn der Prozessor, wenn du ihn direkt auf den Asuro steckst, ohne Sumo Erweiterung? Es könnte ja sein, das das Taktsignal vom Quarz gestört ist. Bei mir steckt der ATmega168 direkt auf dem Asuro.

Der andere ATmega8, der vom Programmer nicht erkannt wird. Ist das der Original Asuro Prozessor? Wenn ja, ist das auch normal, weil beim Asuro Prozessor ISP deaktiviert ist.

Was mir noch einfällt. Ist der Atmega168 vielleicht ein ATmega168P. Ich glaube, da gibt es auch leichte Unterschiede bei den Fuses.

Erst einmal den Part, den ich gleich beantworten kann:

Stimmt, der ATMega8 ist der original Asuro und stimmt, ich hab gelesen, dass bei dem ISP deaktiviert war. Daran hat ich gestern abend nicht mehr gedacht.

Den Asuro 16K hab ich von (http://www.e-robotix.de/epages/61660...ducts/Asuro16K). Da hab ich aber nicht gefunden, dass ISP deaktiviert ist - oder doch?

Den ATMega168 hab ich von e-robotix (http://www.e-robotix.de/epages/61660.../Products/AVR2). Ich muss mal auf der Rechnung nachsehen, was da steht. Erkennt man den Unterschied sonst einfach am Gehäuse/ an der Beschriftung?

Zu den Versuchen: muss ich mal probieren.

Was heisst dann aber : funktionieren? Ich hatte vorher schon einmal Programmcode geflashed. Der müsste dann nach wie vor ausgeführt werden?
Der Asuro mit dem originalen Prozessor läuft - also sollte Prinzipiell der Quarz funktionieren. Das Ansteuern der LEDs und der Motoren hatte auch schon funktioniert (mit aufgestecktem Adapter und ATMega168). Diese Leitungen sind also erst mal nicht gestört.

Ein Osszi hab ich nicht, aber ich muss mal schauen, ob mein Multimeter auch Frequenzen messen konnte. Was gilt es denn zu beachten, wenn man mit einem Multimeter am Prozessor messen will? Hier kommen doch bestimmt Innenwiderstände des Messgerätes ins Spiel? Sprich: macht das überhaupt Sinn?

Der Asuro 16K scheint ein vorkonfektionierter Prozessor mit Bootloader zu sein. Da sind auch die fuses schon eingestellt. Den sollte man mit ISP nicht programmieren, sonst besteht die Gefahr, dass danach der Bootloader weg ist. Könnte aber auch sein, dass ISP wie beim Original Asuro Prozessor deaktiviert ist.

Der ATmega168 wird ein Fabrik frischer Prozessor sein, der mit internem Takt und 1MHz läuft. Den hast du wohl geschrottet. wobei da durchaus noch Hoffnung besteht, ihn wieder zu beleben.

Ob Atmega168 oder ATmega168P ist wohl egal, da habe ich mich geirrt. Die unterscheiden sich nicht bei den Fusebits, sondern nur bei der Prozessor Kennung. Das sollte der ISP Programmer bzw. avrdude selber feststellen, falls da etwas nicht stimmt.

Das eingebrannte Programm kann nur funktionieren, falls auch der Prozessor noch läuft, d.h. wenn er einen Prozessor Takt bekommt. Der Takt ist halt dummerweise von den fuse bits abhängig.

Mit dem Multimeter könntest du z.B. die Versorgungsspannung prüfen, viel mehr aber wohl kaum.

Zuerst zum Multimeter: Es ist ein Voltcraft VC480, das laut Beschreibung

Zitat:

---

sinusförmige Wechselspannung bis max. 10 MHz

---

messen kann. So ähnlich hatte ich das auch in Erinnerung. Nun wird der Takt aber kein Sinus, sondern ja wohl Rechteck sein. Dann gab es noch eine Einschränkung:

Zitat:

---

Bei Spannungen ... kleiner 600 mVrms über 1MHz und < 10 MHz ist keine Frequenzmessung möglich.

---

Schön aber auch, ich kenne mV, was sind denn nun wieder mVrms? Mir ist auch nicht gelungen, irgendwas auf die Anzeige zu bekommen (Quarz Mittelfuss gegen rechtes oder linkes Bein war nix. Und da ich eh unsicher war, ob die Messerei schaden tut, hab ich es dann auch gelassen). Na gut - der Takt scheint ja noch da zu sein -

Die gute Nachricht: Der ATMega168 scheint noch am Leben zu sein. Zumindest tut er genau dass, was ich zuletzt geflashed habe - die Back-LED im Wechsel schalten und die Motoren anzusteuern. Er scheint jetzt auch mit der richtigen Frequenz zu laufen. Zumindest ist der Ablauf jetzt ein ganzes Stück schneller als vor der Manipulation der FUSE-Bits.

Die schlechte Nachricht: ich bekomme nach wie vor keinen Kontakt zum Controller.

Zitat:

---

Enter programming mode: FAILED!

---

ist die spartanische Antwort vom AVR-Studio

Zitat:

---

stk500v2_command() : command failed

---

meint avrdude. Dann hat wohl der Programmer das Abziehen vom USB-Anschluss nicht überlebt? Sind die Teile wirklich derart empfindlich? Oder kann es doch am Controller liegen? Hat sich dort die ISP-Schnittstelle deaktiviert? Dann wiederum sollte mein andere ATMega168 (noch im Originalzustand) doch reagieren (was er nicht tut)!

Was ist eigentlich empfehlenswert als Programmer?
Wenn ich es richtig verstanden habe, nutzt ihr selbst gebaute Programmer. Ich fand die Anbindung über USB ganz entspannt. Es gibt mir auch die Möglichkeit, auf neuere Hardware (Notebook) zu wechseln. Auch das Durchleiten der Versorgungspannung vereinfacht den Aufbau. Das Mappen auf die COM-Ports stört mich aber erheblich. Ich würde es gut finden, wenn die Software gegen USB geht und keinen COM-Port benötigt!

Ich werd blöd: jetzt kann ich den Chip wieder auslesen! Es klappt aber nur, wenn der Programmer nicht mehr die Target-Spannung anlegt. Zumindest für das Lesen. Beim Schreiben muss ich dann die Target-Spannung am Asuro anlegen. Na gut, damit kann ich leben.

Nun komm ich wieder zu meinem ersten Problem: die IR-Kommunikation auf dem Adapter geht nicht. Ich werd jetzt noch mal ein paar Tests mit SetPUTC machen und mir dann erst mal ne Mütze Schlaf holen.

Ok, die letzte Erkenntnis:

1. ) Die IR-Dioden (Front und seitlich) arbeiten. Mit UartPutc wird was gesendet.
2.) Die Zeichen auf der Gegenseite lassen sich nicht rekonstruieren (empfange mit dem IR-Programmer) - scheint wohl Takt irgendwo noch nicht zu stimmen
3.) Die Abstandsmessung sendet keine IR-Signale

Meine Modifizierung (wegen ATMega168)

Code:

---

uint8_t objekt_sichtbar(uint8_t distance)
{
        uint16_t j,z;

          DDRD |= (1 << DDD1);  // Port D1 als Ausgang
          PORTD &= ~(1 << PD1);  // PD1 auf LOW

#if defined(__AVR_ATmega168__)
        OCR2A  = 254-distance;  //OCR2=0xFE ( sehr nahe )
#else
        OCR2  = 254-distance;  //OCR2=0xFE ( sehr nahe )
#endif

        z=0;
        for(j=0;j<30;j++) // loop time: 5ms
        {
                if (PIND & (1 << PD0))z++;
                Sleep(6); // 6*Sleep(6)=1ms
        }
        if (z>=29) return FALSE; // Objekt nicht gefunden
        else return TRUE;

}

// der Rest ist unveraendert, denke ich

uint8_t abstand()
{
        uint8_t k,n;
       
        k=255;
        for(n=0;n<8;n++)
        {
          if (!objekt_sichtbar(n)) k=n; // solange kein Objekt, Distanz erhoehen
        } 
        return k;
}

int main(void){
          uint8_t n;
 
          Init();

        FrontLED(ON);
        StatusLED(OFF);

        n = 0;

          while(1)
        { 
                  n=abstand();
                       
                if(n!=255)
                  {
                          if (n<6) StatusLED(GREEN);
                          if (n<4) StatusLED(YELLOW);
                          if (n<3) StatusLED(RED);
                          if (n<2) BackLED(ON,ON);
                       
                }
                Msleep(10);
        }
}

---

Ich muss ehrlich sein: ich hab noch nicht geschaut, welcher Befehl einen "Beep" über IR-Diode sendet und welcher empfängt. Bin jetzt auch zu müde ...

Moin moin

Ich muss mich hier mal mit ein klinken, da es auch um die FuseBits vom Atmega 168 geht. Ich weigere mich einfach zu akzeptieren, dass ich 5€ für 2 Chips in den Sand gesetzt habe.

Nachdem ich die Fuses verbockt habe - genau wie oben - habe ich mal so, die low SCK Modus von meinem AvrDoper ausprobiert und damit kam ich tatsächlich an meinen Chip ran! Dachte ich mir:

Ok, schnell wieder die Standard-Einstellungen drauf und dann in Ruhe lassen:

Ergebnis, verklickt, zu schnell, da schon lange frustiert damit ...

Jetzt komm ich gar nicht mehr ran. Ich habe mMn Int. RC OSC 128 khz angeklickt. (Da lfuse auf 0x63)

lfuse auf 0x62 wäre mit intern 8Mhz wahrscheinlich sinnvoller gewesen...

Kann es sein, dass mein Programmierer jetzt auch für diese super langsamen 128 khz zu schnell ist?

Ich nutze den AVR-Doper (http://www.obdev.at/products/vusb/avrdoper.html) Kennt sich jemand mit diesem Problem aus?

Ich muss mir das mal anlesen.

Anderes Thema: Gibts denn über High-Voltage Programming ne Möglichkeit dass alles zurückzusetzten auf die Standard-Einstellungen, oder was bringt mir das?

Danke und Entschuldigung, aber ich will das nur schnell runter geschrieben haben, da ich jetzt die Nase voll hab!

Andun

Hi Andun,


mit einem HV-Progger kannst Du das auf jeden Fall wieder gerade biegen.


Gruss,

O.

Ein HV-Programmer kostet aber auch viel im Gegensatz zur ISP Programmierung.