Neuer ATmega reagiert nicht auf ISP

Hallo,

ich hab hier einen neuen ATmega16 (naja, älter aber bisher nie programmiert) der per ISP nicht richtig antwortet.
Als DeviceID kommt immer nur 0xFFFFFF, avrdude bricht dann ab.
Als Programmiergerät hab ich ein mySmartUSB Light (modifiziert um die Spannung vom USB auf den entsprechenden ISP-Pin zu legen, Spannung wollte der nicht mehr von sich aus liefern).
Um den Controller zu programmieren hab ich eine kleine Lochrasterplatine mit einem DIP40-Sockel für den ATmega16, einem DIP28-Sockel für einen ATmega8, einem Abblockkondensator (100nF wenn ich mich nicht irre) und dem 6poligen ISP-Anschluss.
SCK/MISO/MOSI/Reset sind parallel an den DIP28- und DIP40-Sockel gelegt, die Belegung hab ich mehrfach geprüft - ein ATmega8 ließ sich auch problemlos auslesen, auch mit dem Progger-Mod. Natürlich ist immer nur ein µC auf der Platine^^

Ich verstehe nicht ganz warum ich keine gültige DeviceID bekomme, nur ein kaputter Controller scheint mir logisch ...

Deshalb meine Frage an euch: hab ich irgendwas übersehen? Oder kann ich noch irgendwas probieren? Da kommt man mal wieder zum basteln und dann sowas :/

Grüße,
LittleFox

Zitat:

---

... neuen ATmega16 (naja, ... per ISP nicht richtig antwortet ...

---

Es gibt mehrere Möglichkeiten. In Deinem Fall könnte es etwa diese Liste sein:
- Versorgung am DIP40-Sockel ist falsch, wackelt, fehlt . . . Fazit: messen bei ausgesteckten Controllern.
- Falsche ISP-Anschlüsse. Abhilfe: kontrollieren, kontrollieren, kontrollieren, evtl. Drahtbrücken für MOSI, MISO, SCK, GND, Vcc und /RET von der funktionierenden Fassung zur m16-Fassung (aber das könnte dann durch andere Fehler doch wieder gestört werden).
- Fehler im ISP-Anschluss. Es gibt mehr Wackelkontakte auf dieser Welt als wir manchmal annehmen.
- Controller ist DOCH programmiert. Es reicht die Umstellung vom internen Takt auf externen bzw. Quarz - und schon ist man ausgesperrt. Abhilfe z.B. hierdurch (klick) oder einen "richtigen" Taktgenerator.
- Controller defekt. Das kommt selten vor.

Zitat:

---

... DIP40-Sockel für den ATmega16 ... Abblockkondensator (100nF wenn ich mich nicht irre) und dem 6poligen ISP-Anschluss ...

---

Und wenn Du Dich doch irrst? Das Ganze sieht äusserst sparsam aus. Ist der GND für den mega16 auf BEIDEN GND-Anschlüssen? Zeig doch mal bitte Deine Schaltung (KEIN Link auf irgendeine Vorlage!!!).

Zitat:

---

Zitat von oberallgeier

- Versorgung am DIP40-Sockel ist falsch, wackelt, fehlt
- Falsche ISP-Anschlüsse
- Fehler im ISP-Anschluss
- Controller ist DOCH programmiert
- Controller defekt

---

Der häufigste Grund fehlt: ISP-Clock zu hoch, der muss <= 1/4 des µC-Clocks sein. Out-of-the-box läuft der ATM16 mit 1MHz, also ISP-Clock auf 250kHz stellen.

Hi,

danke für eure Antworten.

- Versorgung hab ich geprüft, stabile 4,88V (USB halt)
- ISP ist an die DIP28 und DIP40-Fassung parallel angeschlossen (also von ISP auf DIP40 und von da auf DIP28, DIP28 mit ATmega8 geht problemlos)
- Wackler siehe hier drüber, ATmega8 geht problemlos
- Werde ich probieren, aber da ich den nicht programmieren konnte da mein Programmiergerät kaputt war (deswegen die Spannungsversorgung über USB - gestern erst gemacht) ist das sehr unwahrscheinlich^^
- Wie wahrscheinlich ist ein ESD-Defekt?

Ist auch sehr sparsam, dient ja nur zum programmieren während ich keine Platine hab (Steckbrett, hätte mir da eher einen Adapter für Steckbrett bauen sollen ...) - sowohl m8 als auch m16 nur mit einem GND verbunden, probier das aber mal aus

Macht der Programmer das nicht selber?

- - - Aktualisiert - - -

Also beide GND Pins verbinden bringt auch nix ...

Update zum Verhalten des Controllers: manchmal kommen nur einsen, manchmal nur nullen und manchmal nix ...

Liest er denn den Controllertyp richtig aus?

Setz mal die Programmierfrequenz auf 1/10 des µC Taktes.

Drücke den IC mal mit dem Finger richtig ins Steckbrett, während du auf ihn zugreifen möchtest. Ich hatte das auch schon, dass ein Kontakt halt nicht kontaktiert hat.

Hi,

sorry wegen der späten Antwort - war am WE nicht da und gestern beschäftigt ...

Nein, den Controllertyp liest es nicht richtig aus - wie geschrieben entweder nur 0xFFFFFF oder 0x000000 - oft auch Timeout ...
Ich denke mal der ist einfach nur kaputt und werd mal einen neuen kaufen, geht schneller - wenn der auch ne geht hab ich halt einen auf Reserve und kann ja weiter suchenˆˆ

Danke trotzdem an alle :)

Vieleicht ist auch ISp beim µC verkorkst und es sollte mal per High-voltage Programmierung versucht werden. So habe ich auch schon "totgeglaubte" Chips wieder zum Leben erweckt, auf 'nem STK500 ist das ja ratz fatz gemacht.

Gruss
OL