Forum: Mikrocontroller und Digitale Elektronik ATMega324PA kann nicht per ISP angesprochen werden (kein MISO-Signal)


von n.G. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

ich versuche seit über einer Woche alles Mögliche, aber komme einfach 
auf keine sinnvolle Lösung und hoffe deshalb, dass ihr mir weiterhelfen 
könnt.

Das Problem: Ich kann meinen ATMega324PA(TQFP) per ISP komplett gar 
nicht mehr ansprechen, also schon das Signatur readen schlägt fehl.
Ich habe 3 Platinen und bei allen ist das der Fall, den ATmega habe ich 
bestücken lassen, also an meinen Lötkünsten kann es nicht liegen. Auch 
Programmer und PC-Software(AVR Studio 4 und 6) scheiden aus und die 
Verkabelung stimmt auch, einen ATMega16(DIP) auf dem Steckbrett kann ich 
nämlich auch noch programmieren. Die ISP-Leitungen waren ursprünglich 
mit den SPI-Leitungen von 3 Slaves zusammengelegt, allerdings habe ich 
diese bei der Fehlersuche gecutted, ebenso die Stromzufuhr aller anderen 
Chips. Das bedeuted, dass wirklich nur noch der ATMega an MISO, MOSI, 
SCK und RES hängt.

Bei der Untersuchung mitm Oszi hat sich gezeigt, dass SCK, MOSI und RES 
vom mkii richtig initialisiert werden, aber auf MISO kommt etwas seeehr 
seltsames: Während des Versuchs, die Signatur zu lesen, springt MISO von 
0V auf 2,7V (VCC=5V). Das ließe sich mir nur dadurch erklären, dass MISO 
mit irgendeinem anderen Pin verbunden ist, aber ich habe alles 
durchgemessen. Oszillogramm i.A. (blau MISO, gelb MOSI).
Allerdings kommt das nur so, wenn der MISO mit dem mkii verbunden ist, 
wenn man den als einzigen aussteckt bleibt er low. Pullup bringt leider 
auch nix, dann bleibt MISO immer high. Also nochmal: All die Messungen 
sind während des "Read Signature"-Versuchs (ISP-freq: 6,478khZ). Den 
Quarz (18,432MHz) habe ich bei der dritten Platine jetzt mal 
weggelassen, jetzt läuft der AVR mit den internen 8MHz aber das gleiche 
Problem. :(

Hat jemand eine Erklärung für den seltsamen MISO-Pegel? Ich weiß nun 
echt nicht mehr weiter und will die Platinen nicht alle wegwerfen, es 
kann ja nicht sein dass der nagelneue AVR nicht programmierbar ist 
(wurde noch nie programmiert, kann also auch nicht vefused sein).
Bin für jeden Tipp, was das sein könnte und wie ich den wieder 
ansprechen kann schon mal dankbar!

Gruß, Jonas

von Marc H. (marchorby)


Lesenswert?

Mach bitte ein Foto vom Aufbau!

von n.G. (Gast)


Lesenswert?

Naja viel lässt sich da nicht erkennen, 5V und GND vom Netzteil zur 
Platine und die ISP-Verbindung zum mkII - mehr ist momentan nicht 
angeschlossen.
Trotzdem?

von Marc H. (marchorby)


Lesenswert?

n.G. schrieb:
> Naja viel lässt sich da nicht erkennen, 5V und GND vom Netzteil zur
> Platine und die ISP-Verbindung zum mkII - mehr ist momentan nicht
> angeschlossen.

Mach bitte ein Foto vom Aufbau!

von n.G. (Gast)


Angehängte Dateien:

Lesenswert?

Netzgerät<<<        >>>PC

von Marc H. (marchorby)


Lesenswert?

Der ATMega 324 ist links?

Du hast bei dem Fehlerbild den externen takt aktiv! Entweder XTAL oder 
OSC bzw ext OSC bei XTAL. Bei OSC gibt der AVR kein "Anstupssignal" und 
kann dann nicht mehr gelesen/gelöscht werden...

Externen Takt an XTAL-Pin reicht normaler weise

Mach von deiner Platine mal ein besseres Foto! Am besten detailreich und 
ggf nen Schaltplan/Layout falls verfügbar! Nutzt Du eagle? Bitte beide 
sch und .brd hochladen!

: Bearbeitet durch User
von n.G. (Gast)


Lesenswert?

Ja der 324PA ist links

Danke schon einmal für die Idee, bei der anderen Platine habe ich schon 
versucht an XTAL1 1MHz über einen anderen AVR einzuspeißen, hat aber 
leider nicht geklappt. Werde aber morgen auch bei der Platine einen 
Versuch starten, oder einfach den Quarz auf die dafür vorgesehen pads 
unter dem atm löten.

Leider darf ich von der Platine kein ganzes Foto machen, ebenso wenig 
wie von Schaltplan und Layout, weil das in Kooperation mit einem 
Unternehmen entwickelt wurde. Aber bevor du denkst: "Wie soll ich helfen 
wenn ich seine Hardware nicht kenne": Ich bearbeite Schaltplan und 
Layout morgen so, dass alles wichtige da ist und lade es hoch, melde 
mich auch bzgl. der Ergebnisse mit dem externen Takt.
Danke nochmals!

von Klaus (Gast)


Lesenswert?

Marc H. schrieb:

> Du hast bei dem Fehlerbild den externen takt aktiv! Entweder XTAL oder
> OSC bzw ext OSC bei XTAL. Bei OSC gibt der AVR kein "Anstupssignal" und
> kann dann nicht mehr gelesen/gelöscht werden...
>
> Externen Takt an XTAL-Pin reicht normaler weise

Ich fürchte ich kann zu dem Problem nichts weiter sagen, aber mich 
interessiert das.
Magst Du Deine Erklärung von oben mal etwas ausführlicher oder mit 
anderen Worten wiederholen, bitte? Ich kann Dir leider nicht folgen. 
Unter einem  "Anstupssignal" kann ich mir z,B, nichts vorstellen. Auch 
wird mir nicht klar, ob das mit dem externen Takt nun funktioniert oder 
nicht. Der erste Satz und der letzte scheinen sich darin zu 
widersprechen.

von Justus S. (jussa)


Lesenswert?

Klaus schrieb:
> Der erste Satz und der letzte scheinen sich darin zu
> widersprechen.

er meint, dass der AVR auf externen Takt eingestellt ist, dieser aber 
nicht angelegt wurde. Und dass es so dann laufen müsste/könnte, wenn ein 
externer Takt angelegt wird.

Klaus schrieb:
> Magst Du Deine Erklärung von oben mal etwas ausführlicher oder mit
> anderen Worten wiederholen, bitte?

ein ATmega/tiny braucht einen Takt, auch wenn er 'nur' programmiert 
wird. Das kann der interne sein, ein externer Quarz, ein externer Takt 
oder wasauchimmer der spezielle AVR kann. Wenn der µC also zB auf einen 
externen Quarz eingestellt ist, es diesen aber nicht gibt, kann man ihn 
nicht so programmieren

von 小鬼 (Gast)


Lesenswert?

n.G. schrieb:
> Das Problem: Ich kann meinen ATMega324PA(TQFP) per ISP komplett gar
> nicht mehr ansprechen, also schon das Signatur readen schlägt fehl.

Hast du es mal ganz normal mit lesen probiert?

von Draco (Gast)


Lesenswert?

小鬼 schrieb:
> Hast du es mal ganz normal mit lesen probiert?

Wenn der Progger nichtmal die Signatur lesen kann, kann er auch nicht 
den Flash lesen, ich denke auch das es am Quarz. Software ist auf dem 
Mega drauf, dafür ist ein externer Quarz vorgesehen und den gibt es 
nunmal nicht.

Bei einem Mhz Takt den du angelegt hattest, musst du bedenken das dein 
ISP Takt dementsprechend auch kleiner sein muss. Einfach mal auf dieser 
"Testplatine" mal mit dem niedrigsten zur Verfügung stehenden ISP Takt 
versuchen. Genau aus diesem Grund baut man sich einen Programmierer 
welchen auch einen Takt mit auf einem Pin herrausführt! Mal so für die 
Zukunft. Aber ist eigentlich ist das ja bei dir im Aufbau schön einfach 
gemacht, mit den Pads die rausführt sind.

von n.G. (Gast)


Angehängte Dateien:

Lesenswert?

Okay, danke bereits für die Hilfsversuche

Draco schrieb:
> Bei einem Mhz Takt den du angelegt hattest, musst du bedenken das dein
> ISP Takt dementsprechend auch kleiner sein muss

Ja, Standard ISP-freq bei meinen Tests ist 6,48kHz; habs aber auch schon 
mit 51.1Hz versucht.

Ich habe nun auch bei der jetzigen Platine 1MHz und 1kHz an XTAL1 u. 
XTAL2 (die 2 Pads unter dem AVR) hingehalten, gleiches Fehlerbild.

Quarzbeschaltung siehe anhängendes Layout.
Die SPI Leitungen wurden wie gesagt gecutted und der nicht im Ausschnitt 
liegende Teil der Platine gehört zu Schaltungen bzw. Kommunikation mit 
anderen Chips, die alle aus sind (Stromzufuhr gekappt).

von n.G. (Gast)


Lesenswert?

X2 ist noch mit einem 22pF Kondi gegen gnd geschaltet, hab ich 
abgeschnitten, sorry

von n.G. (Gast)


Lesenswert?

Keiner mehr ne Idee? Wenn ich irgendwas testen soll oder ihr weitere 
Informationen braucht bitte sagen

von Klaus (Gast)


Lesenswert?

Justus S. schrieb:
> Klaus schrieb:

Ah. Gar nicht gesehen, das da geantwortet wurde. Dankeschön. Das ist 
auch mein Kenntnisstand gewesen.

von n.G. (Gast)


Lesenswert?

Habe gerade noch MISO von der Platine abgesteckt und am AVRISPMkII 
direkt gemessen während des Signaturlesens (klar dass es dann nicht 
funktioniert). Es gibt die selbe Kurve wie im ersten Post dargestellt, 
wo miso angesteckt war, macht also gar keinen Unterschied ob mit dem 
atm324pa verbunden oder nicht. Miso (eig ja Output) ist also am avr 
anscheinend hochohmig, Verbindung zum Prozessorpin ist da. Konnte aber 
noch nie programmiert werden, also kann ja nicht verfused sein. Habe 
auch schon mit dem Dragon versucht zu proggen, also am programmer 
liegt's nicht.

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Lesenswert?

Hi,
da dies ein kommerzielles Projekt ist und nach einer Woche immer noch 
nichts funktioniert, wäre die sinnvollste Lösung, wenn Du Dich gemeinsam 
mit einem Profi dransetzen würdest.
Aus dieser gemeinsamen Sitzung ziehst Du sicher eine Menge Vorteile, die 
auch über das aktuelle Problem hinausgehen.
Schau mal ob Du jemanden bei Dir in der Nähe findest.
Grüße,
 Marcus

P.S.: Ich habe die letzten zwei Tage so eine Schulung hier im Haus 
gehalten. Thema waren die Erstinbetriebnahme und die Portierung von 
Kundenfirmware bei einer neuen Baugruppe.
Zu Beginn ging gar nichts. Am Schluss liefen RS232, RS485, RTC, 
Webserver, SDcard. Und sogar die Status-LED hat geblinkt. ;)

von n.G. (Gast)


Lesenswert?

Marcus H. schrieb:
> da dies ein kommerzielles Projekt ist und nach einer Woche immer noch
> nichts funktioniert, wäre die sinnvollste Lösung, wenn Du Dich gemeinsam
> mit einem Profi dransetzen würdest

Ihr seid doch alles Profis ;)
Aber hast schon recht, werde das mit dem Unternehmen, für das wir (Team 
aus Nichtmalstudierten) das entwickeln sollen diskutieren, hab nur 
gehofft dass wir das auch so schaffen :)

Trotzdem wenn jmnd ne Vermutung hat was das sein könnte bitte
                                                       |
                                                      V

von S. Landolt (Gast)


Lesenswert?

Was mir auffällt:

> Ich kann meinen ATMega324PA(TQFP) per ISP komplett gar
> nicht mehr ansprechen
> der nagelneue AVR ... wurde noch nie programmiert
Von "nicht mehr" kann also nicht die Rede sein, sondern von "überhaupt 
nicht".

> Den Quarz (18,432MHz) habe ich bei der dritten Platine
> jetzt mal weggelassen, jetzt läuft der AVR mit den
> internen 8MHz
Wieso "jetzt"? Ein neuer ATmega324PA läuft mit 1 MHz intern.

Könnte es sein, dass es da an Systematik und Grundlagen mangelt?


Was mir einfällt:

Betriebsspannung messen, direkt am uC. Durchgang der 
Programmierleitungen messen, vom Programmiergerät bis zum uC, wieder 
jeweils direkt an den Pins. Übergangswiderstände zwischen den 
Programmierpins untereinander und zu den Versorgungspins des uC messen, 
vielleicht zeigen sich dabei Auffälligkeiten.

von Paul B. (paul_baumann)


Lesenswert?

>> Ich kann meinen ATMega324PA(TQFP) per ISP komplett gar
>> nicht mehr ansprechen
>> der nagelneue AVR ... wurde noch nie programmiert

Ich hatte diesen Effekt bis heute einmal: Eine Lieferung von 10 Atmega8, 
bei der 3 Stück kein Lebenszeichen abgaben. Lösung: Die waren nicht 
nagelneu, sondern schon alle mit (dem gleichen) .hex "bespielt".

Das brachte mich seinerzeit dazu, diese Schaltung:
http://mdiy.pl/atmega-fusebit-doctor-hvpp/?lang=en
zu bauen. Seither kommt jeder neue Kontroller erstmal dort dran.

MfG Paul

von S. Landolt (Gast)


Lesenswert?

Da wäre die Nennung des Lieferanten von Interesse.

von Paul B. (paul_baumann)


Lesenswert?

S. Landolt schrieb:
> Da wäre die Nennung des Lieferanten von Interesse.

Kann ich nicht mehr sagen -ist zu lange her. War über Ebay ersteigert, 
aber kein Privatmann.

Es lehrt aber, daß edr Fehelr nicht immer beim Benutzer und dessen 
Apparaten liegt.

MfG Paul

von S. Landolt (Gast)


Lesenswert?

Da bereits (angeblich) alles Mögliche versucht wurde, hieße das, dass 
die drei ATmega324PA mit fuse SPIEN disabled geliefert wurden - kann ich 
mir zwar nicht vorstellen, aber da kann ich auch nicht wirklich 
mitreden; ich hatte in anderthalb Jahrzehnten mit Atmel-AVRs nie 
Probleme, bei Lieferungen von Reichelt und Digikey.

von n.G. (Gast)


Lesenswert?

Habe die Atmegas von Farnell:
http://de.farnell.com/atmel/atmega324pa-au/mcu-8bit-avr-32k-flash-44tqfp/dp/1715482

S. Landolt schrieb:
> Wieso "jetzt"? Ein neuer ATmega324PA läuft mit 1 MHz intern.

Ja stimmt, hab mich vertan, hatte die CKDIV8-Fuse vergessen, aber sollte 
ja bei 6.48kHz nichts ausmachen.

Paul B. schrieb:
> Das brachte mich seinerzeit dazu, diese Schaltung:
> http://mdiy.pl/atmega-fusebit-doctor-hvpp/?lang=en
> zu bauen. Seither kommt jeder neue Kontroller erstmal dort dran.

Ok, interessante Idee, ich hab mir 0.8RM Stecker bestellt, um an die 
Pins ranzukommen, kann ich dann probieren.

Haltet ihr HVPP zu versuchen für sinnvoll?

von guest (Gast)


Lesenswert?

n.G. schrieb:
> Haltet ihr HVPP zu versuchen für sinnvoll?

Probieren kann man es, JTAG wär auch noch eine Alternative.
Hängt da bei Dir noch irgenwas am Reset (R1,Cxx)? Ist auf Deinem Bild 
nicht wirklich zu erkennen.

von n.G. (Gast)


Angehängte Dateien:

Lesenswert?

guest schrieb:
> Probieren kann man es, JTAG wär auch noch eine Alternative.
> Hängt da bei Dir noch irgenwas am Reset (R1,Cxx)? Ist auf Deinem Bild
> nicht wirklich zu erkennen.

Danke, anbei der relevante schaltplanteil, JTAG probiere ich morgen.

von Beobachter (Gast)


Lesenswert?

n.G. schrieb:
> Miso (eig ja Output) ist also am avr anscheinend hochohmig

Warum klärst du das nicht und verläßt dich auf irgendwelchen Anschein?

Ein (hochohmiger) 1:1 Spannungsteiler zwischen VCC und Gnd mit dem 
Abgriff an MISO verrät dir bei Betrachtung mit dem Oszi sofort, ob 
irgendjemand die Leitung auf einen vernünftigen Logikpegel zieht, oder 
ob sie frei in der Luft hängt.

Und C16, C17 haben sicher einer Wert von 22pF (und nicht 22nF)?

von Planlos (Gast)


Lesenswert?

n.G. schrieb:
> IMG_20150821_025620.jpg

Zwei Fehler seh ich, haben leider beide nichts mit SPI zu tun.
1) Bildformate
2) Kurzschluss Aref <-> 5V

Aref ist je nach ADC-Config ein Ausgangs-Pin. Eine Verbindung an die 
Versorgungsspannung ist dann ein Kurzschluss.
Einen Grund Aref mit VCC zu verbinden gibt es bei keinem der in den 
letzten Jahrzehnten erschienen AVRs mehr.
Wenn man wirklich VCC als Referenz für den ADC verwenden will, kann man 
das per Software einstellen.
Der Kondensator an Aref ist richtig.

von Planlos (Gast)


Lesenswert?

Planlos schrieb:
> 2) Kurzschluss Aref <-> 5V

Marcus H. schrieb im Beitrag #4242085:
> Nun erstmal das Beinchen heben,

Na, so wild ist das erstmal nicht.
Solang die Software nicht an den REFS-Bits herumspielt, passiert nix 
böses.
Und ob der ADC überhaupt verwendet wird, sieht man am Schaltplan ja 
nicht.

das SPI-Problem muss woanders liegen.

von grundschüler (Gast)


Lesenswert?

Isp-pins von Platine trennen und separat mit Programmer verbinden. 
Notfalls m324 komplett auslöten. Zuerst feststellen, ob Fehler an der 
paltine oder am m324 liegt. Dann gehts weiter.

von guest (Gast)


Lesenswert?

Auch mal nachmessen, ob R1 wirklich 10k hat, bzw. ob der Reset-Pin 
wirklich gegen Masse gezogen wird. Zum Testen kann man R1 auch mal 
auslöten.

von n.G. (Gast)


Lesenswert?

Prozessoren waren wohl wirklich defekt, habe den alten abgelötet und 
einen neuen drauf; der lässt sich ohne Probleme ansprechen.

Trotzdem Danke für die vielen Hilfsversuche!

von Roland (Gast)


Lesenswert?

Hallo n.G.(Gast),

das Problem mit dem Pin MISO kenne ich auch. Mit einem Oszi
kann man an diesem Pin etwas "wackeln" sehen aber mit klaren
Pegeln hat das nichts mehr zu tun.
Bei mir hatten die AVRs (ca. 3 bis 4 Stück) am Anfang funktioniert, bei
welcher Gelegenheit der Pin MISO zerstört bzw. beschädigt wurde, ist
mir allerdings ein Rätsel. Ich wollte es mit HVPP nochmal probieren,
zur Zeit mangelt es aber noch an der Hardware (ISP ist ja eigentlich
ausreichend).

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.