-         

Ergebnis 1 bis 6 von 6

Thema: Atmega32, Signature, Fusebits

  1. #1

    Atmega32, Signature, Fusebits

    Anzeige

    Hallo zusammen.

    Ich habe schon eine weile bei euch gelesen, komme aber anscheinend nicht weiter (oder sehe den Wald vor Bäumen nicht mehr).
    Das Thema ist auch nicht wirklich neu, aber ich bekomme keinen echten Zusammenhang.

    Zum Aufbau:
    Grundschaltung laut Datenblatt
    Der Quarz hat Cl=32pF, also habe ich entsprechend der Infos die ich gefunden habe das ganze um 2x drei parallel geschaltete Kapazitäten á 22pF (=2x66pF) ergänzt um die 16MHz zu bekommen. Leider löst mein Oszilloskop nicht soweit auf um zu sehen, ob die wirklich vorhanden sind oder nur vorhanden sein müssten.
    Es ist ein 6pol-ISPanschluss vorhanden und ein Resetknopf, der laut Oszilloskop tatsächlich auf GND geht. Außerdem lässt sich der Reset Messen, wenn der ISP verwendet wird.
    Der ISP läuft auf 51,1Hz (absolutes Minimum).
    Als GUI habe ich AVR Studio 4.14 Build 589, der Programmer hat die aktuelle Firmware.


    Folgendes Problem:
    Ich möchte einen Atmega32 mit einem AVR ISP mkII programmieren und dafür mit einem externen Quarz bei 16MHz betreiben.
    Ich scheitere schon bei der Einrichtung meines AVR (Fuses etc.).
    Die Signatur, die ich auslese ist entweder immer eine Andere oder "0x73 0x73 0x73" (Bei sechs µC probiert) Hier ist doch was faul, die Signatur sollte doch wenigstens mal mit 0x1e Anfangen (angeblich steht das für "von Atmel gebaut")???!
    Gelegentlich verändert sich von read zu read auch die konfiguration der Lockbits und der Fuses - für LB tritt regelmäßig der Eintrag "undefined value: 0x01" auf.
    Ab und zu, ohne das ich einen Zusammenhang finden kann, wird mein Programmer nicht mehr erkannt ("connection failed")

    Wenn ich einen AVR drinn hatte, bei dem zumindest immer das selbe ausgelesen wurde, dann habe ich mal versucht die Taktquelle zu setzen.
    Es passiert allerdings nicht viel:
    Entering programming mode.. OK!
    Writing fuses address 0 to 1.. 0x53, 0x5B .. OK!
    Reading fuses address 0 to 1.. 0xFF, 0xFF .. OK!

    WARNING: Fuse bits verification.. FAILED
    Leaving programming mode.. OK!


    In diesem Fall habe ich die Werte, die aus dem AVR gelesen wurden zurück schreiben lassen. Wenn ich lesen lasse wird in diesem fall immer das selbe zurückgelesen und ein verify alleine fällt positiv aus.

    Nun die Frage:
    Was kann ich alles übersehen/überlesen haben? Bzw. Was mache ich möglicherweise offensichtlich falsch.
    Mir würde es für den Moment vollkommen genügen, wenn ich eine korrekte Signatur bekomme und die Fusebits korrekt setzen kann.


    Vielen Dank schoneinmal im Voraus.

  2. #2
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    07.07.2006
    Ort
    Mannheim
    Beiträge
    454
    Neu ist der Atmega32 immer auf internen Takt 1MHz (und JTAG) eingestellt, d.h. du kannst die ISP Frequenz auf ca. 100kHz einstellen. Hab auch schon gehabt, das es auf Minimum nicht läuft. Der Quarz ist dabei im Moment wurscht. (Imho sind die 66pF zu hoch). Die unterschiedlichen Ausleseergebnisse deuten auf Wackelkontakt, zu lange Leitung oder schlechte Versorgungsspannung.

  3. #3
    Danke für die Antwort...

    Es gibt also auch eine zu kleine ISP-Freq?! Das Probier ich nachher einmal aus.

    Wackelkontakt hab ich schon überlegt, aber ich such besser noch ein drittes mal.
    Wie lang dürfen die Wege zwischen Atmega und Stecker zum Programmiergerät erfahrungsgemäß sein? Habe das ganze auf einer Streifenplatine aufgebaut, µC in der Mitte, Anschlüsse aussen. Könnten So 5-6cm sein...
    Ich versorge meine Schaltung aus einem ATX-Netzteil mit einer verpolschutzdiode dazwischen (falls ich die Versorgung verkehrt herum anlege). Kann das die Quelle meiner Probleme sein? Habe eigentlich gehoft, das ein Netzteil das sonst einen PC versorgt gut genug ist...


    Gruß,
    Kay

  4. #4
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Eine zu langsame ISP Frequenz sollte es eigentlich nicht geben. Es wird nur unangenehm langsam. Außerdem gibt es Probleme die gegelegentlich auftreten,da hilft es dann wenn es nicht zu langsam ist.

    Die Kabel der ISP Verbindung, d.h. vom Controller bis zum ISP Adapter sollten nicht unbedingt länger als ca. 30 cm sein. Das Hängt aber auch vom programmierer ab. Bei einem gut gemachten interface und nicht zu hoher Frequenz sollten auch 1-2 m noch gehen. Bei einer schlechten Schaltung können auch 10 cm schon zu viel sein.


    Das Computernetzteil könnte ein Problem sein: Praktisch ohne Last kann die Spannung zu hoch sein. Sollte eigentlich nicht, wegen Standby modus, aber dafür sind die netzteile nicht unbedingt gebaut. Die Schutzdiode sollte nicht das Problem sein, solange sie richtig herum ist. Sind denn Abblockkondensatoren (für VCC-GND und AVCC-AGND) vorhanden ?

  5. #5
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    07.07.2006
    Ort
    Mannheim
    Beiträge
    454
    Stimmt, eine zu niedriege Frequenz sollte es nicht geben. Aber whatever it was, bei Takt von 14,xxx MHz lief es bei Minimum ISP über STK500 nicht, war aber die Vorgängerversion vom AVR Studio. Tut hier eigentlich nix zur Sache, sollte aber erwähnt werden.
    Mit dem Kabel halte ich es relativ kurz und nehme die STK-Kabel von ca. 15cm.
    Wenn aber schon dein MKII nicht immer erkannt wird, kann es doch nur an der Verbindung zum PC liegen. Nimm mal ein anderes Kabel oder benutze einen anderen Port.
    IMHO gab es auch ein Firmware Problem mit dem MKII. Check doch mal bei AVR.

  6. #6
    Nochmal Danke für die Antworten...


    MKII hängt am USB und an dem Rechner habe ichnur einen USB-Controler.
    Den Kondi bei AVCC-AGND hab ich natürlich schonmal vergessen.

    Werde die Schaltung nochmal aufbauen und ein anderes Netzteil nehmen.
    Melde mich dann nochmal zurück und erzähl mal was das gebracht hat.

    Bis dahin schon einmal Danke!
    Gruß,
    Kay

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •