-         

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 11

Thema: Hilfe ich kann meinen Atmega2651 nicht mehr ansprechen!

  1. #1
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    19.02.2008
    Ort
    Pohlheim
    Alter
    27
    Beiträge
    240

    Hilfe ich kann meinen Atmega2651 nicht mehr ansprechen!

    Anzeige

    Hi,

    ich habe gerade mein Atmega2561-board fertig gebaut. Konnte per Bascom auch sofort auf den Chip zugreifen.
    Hab erstmal den JTAG deaktiviert. Danach ein einfaches Programm gespeichert, womit nur ein Ausgang "blinkt". Funzt! Nachdem ich nochmal in die Fusebits geschaut habe, hab ich gesehn, dass "divide clock by 8" enabled war. Hab das disabled und nun kann ich auf den Chip nichtmehr zugreifen! =( An der Taktquelle hab ich nichts geändert. Im Programm hab ich auf 8 Mhz stehen und in den Fusebits Int. RC Oszillator.

    HILFE!!!!

  2. #2
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    35
    Beiträge
    1.987
    Wie sicher bist du dir, dass du wirklich _nur_ dieses CKDIV8-Fuse geändert hast? Gleiches hatte ich auch schon mal, da hab ich "irgendwie" noch das RSTDISBL aktiviert.

    Kannst du die Fuses noch auslesen?
    #ifndef MfG
    #define MfG

  3. #3
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    19.02.2008
    Ort
    Pohlheim
    Alter
    27
    Beiträge
    240
    Hi,

    ich hab definitiv nur den clockdiv geändert. Da bin ich mir absolut sicher. Ich komm leider auf gar nixmehr drauf. Auch läuft das Programm was auf dem µC drauf ist (blinkender Ausgang) auch nicht ab.

    Gibts da noch ne möglichkeit das zu ändern? Ich hab nur den normalen Parallelport Adapter.

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    35
    Beiträge
    1.987
    Schon komisch das Ganze.
    Wie schaut denn die Resetbeschaltung aus? Ist da ein Pullup nach Vcc dran?

    Andere, gern übersehene Dinge: Beim Programmer der richtige AVR ausgewählt und die ISP-Frequenz max. 1/4 von F_CPU?

    Wenn der AVR nicht beschädigt ist, kommt man eigentlich per HV-Programmer drauf. Wäre aber bei dem (sehr wahrscheinlich SMD) ne ziemliche Fusselei, da alle Pins zu erwischen.
    #ifndef MfG
    #define MfG

  5. #5
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    19.02.2008
    Ort
    Pohlheim
    Alter
    27
    Beiträge
    240
    Hi,

    hab heute bei genauerem hinschauen und kontrollieren des Layouts entdeckt, dass zwar alle VCC Pins verbunden waren, aber nirgends angeklemmt sind! Ausser am Reset-Pullup. Kann der Chip dadurch kaputt sein?

    Aber komisch, dass ich ihn trotzdem programmieren konnte und er auch funktioniert hat^^ Vermutlich wurde er da über die PC Schnittstelle irgendwie versorgt... Hab jetz Spannung drauf, aber trotzdem keine änderung. Weder Zugriff, noch tut er irgend etwas.

    Gruß

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    35
    Beiträge
    1.987
    D.h. die Vcc-Pins kriegen 5V über den Reset-Pullup?
    Naja, zerstört wird dadurch nix; nur reicht der Saft halt dann kaum für nen anständigen Betrieb.
    Was möglich wäre: Bei CKDIV aktiv war die Frequenz niedriger => geringerer Energiebedarf; da hats dann gereicht. CKDIV deaktiviert => Frequenz höher => mehr Saft benötigt.

    Kannst du mal irgendwie nen Schaltplan aufstellen, wie der AVR jetzt im Moment angeschlossen ist?
    #ifndef MfG
    #define MfG

  7. #7
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    19.02.2008
    Ort
    Pohlheim
    Alter
    27
    Beiträge
    240
    Hi,

    wenn es keinen schaden genommen hat, sollte es aber nun funktionieren oder? Die beschaltung ist einfach. Alle VCC, VREF ect. an +5V und alle GND an GND. Der Reset is über 10K an VCC. VCC beträgt 5V. Hab an allen Pins direkt gemessen.

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    35
    Beiträge
    1.987
    Das Einzige, was ich jetzt noch vermuten würde: Die Clock-Fuses haben sich durch nen Übertragungsfehler doch verstellt. Kann gut sein, dass der EEPROM-Bereich mit den Fuses durch die zu geringe Spannung unvollständig programmiert wurde.

    Welche Taktquelle hat der AVR denn? Intern oder ext. Quarz?
    Falls intern und sofern Zugang möglich/Teile vorhanden: Auf einem 2. AVR (welcher ist egal) einen Pin in ner while(1) togglen lassen und den an XTAL1 vom Mega2561 legen. Wenns wirklich ne falsche Taktquelle war, müsste er jetzt wieder antworten (ISP-Frequenz dabei runterdrehen)

    Kannst du testweise den Programmer mal an nem anderen AVR testen bzw. den 2561 ohne laufen lassen? Nicht dass der Programmer nen Hau hat.
    #ifndef MfG
    #define MfG

  9. #9
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    19.02.2008
    Ort
    Pohlheim
    Alter
    27
    Beiträge
    240
    Falls intern und sofern Zugang möglich/Teile vorhanden: Auf einem 2. AVR (welcher ist egal) einen Pin in ner while(1) togglen lassen und den an XTAL1 vom Mega2561 legen.
    du meinst extern oder?

    Also eingestellt habe ich auf Intern, bzw. die Standardeinstellung ist drinne.

    Programmer und AVR sind zwar auf der gleichen Platine, aber mittels Jumper kann man die trennen. Geht leider trotzdem nicht =/

    Gruß

  10. #10
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    35
    Beiträge
    1.987
    Jein. Also falls er auf intern stehen sollte, aber - warum auch immer - trotzdem auf extern steht, dann kann man an XTAL1 den erwarteten Takt einspeisen. Dann müsste sich der AVR wieder melden, wenns das war.
    #ifndef MfG
    #define MfG

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

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