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
Mach bitte ein Foto vom Aufbau!
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?
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!
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
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!
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.
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
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?
小鬼 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.
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).
X2 ist noch mit einem 22pF Kondi gegen gnd geschaltet, hab ich abgeschnitten, sorry
Keiner mehr ne Idee? Wenn ich irgendwas testen soll oder ihr weitere Informationen braucht bitte sagen
Justus S. schrieb: > Klaus schrieb: Ah. Gar nicht gesehen, das da geantwortet wurde. Dankeschön. Das ist auch mein Kenntnisstand gewesen.
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.
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. ;)
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
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.
>> 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
Da wäre die Nennung des Lieferanten von Interesse.
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
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.
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?
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.
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.
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)?
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.
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.
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.
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.
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!
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.