Hallo Zusammen, im Rahmen von Hobby-Elektrobastelei versuche ich derzeit eine selbst erstellte Platine mit einem ATmega32u4 in Betrieb zu nehmen. Dabei funktioniert leider bisher gar nichts und ich bin mit meinen Ideen am Ende. Jeder ATmega32u4 wird vom Werk aus mit einem vorprogrammierten USB DFU Bootloader ausgeliefert. Das initiale Vorhaben war daher die Programmierung per USB vorzunehmen. Dies funktioniert nicht und soll hier auch erstmal weiter keine Rolle spielen. Als eine Art "Hintertür" wurden verschiedene Pins des ATmega32u4 auf eine Stiftleiste geführt - darunter auch die Pins zur Programmierung mittels ISP (SCK, MISO, MOSI, #RESET, GND und VCC = 5V). Die Stiftleiste und der Controller sind im ersten Bild "Schematic.png" zu sehen. Mit einen AVR ISP mkII versuche ich nun derzeit vergebens eine Verbindung mit dem ATmega32u4 herzustellen. Bereits der erste Schritt "Entering programming mode" schlägt fehl. Nach viel Sucherei und experimentieren, konnte ich das Problem auf das Taktsignal der ISP bzw. SPI eingrenzen. Das zweite Bild "SPI_Clock_Compare.png" zeigt: Gelb: SPI Clock von AVR ISP mkII nicht an die Platine angeschlossen Grün: SPI Clock von AVR ISP mkII an die Platine angeschlossen Einstellung sind 5V/Div mit bei einer SPI-Taktfrequenz von 1kHz. Deutlich zu sehen ist, dass bei dem grünen Signal die Differenz zwischen High und Low des SPI-Taktsignals nur ca. 1V beträgt und der ATmega32u4 somit natürlich keine Flanken erkennt. In dem gezeigten Ausschnitt des Schematics ist die Leiterbahn des SPI-Takts (SCK) hervorgehoben. Es sind keine Bauteile oder ähnliches Vorhanden. Elektrische Verbindungen zu danebenliegenden Leiterbahnen oder Pins des ATmega32u4 existieren nicht. Alle sonstigen Signale der ISP-Schnittstelle (MISO, MOSI, #RESET, GND und VCC) sehen gut aus. Das letzte Bild zeigt noch einmal des Systemtakt (Grün) im Vergleich zum SPI-Takt (Gelb). Testweise wurde hier ein externer Takt erzeugt und direkt an XTAL1 des ATmega32u4 angeschlossen. Quarz (Q1) und Kapazitäten (C1, C2) (siehe Schematic) sind derzeit nicht bestückt. Das CLKDIV8-Fuse-Bit sollte nicht gesetzt sein, da für den vorprogrammierten Bootloader 8 MHz oder 16 MHz benötigt werden. Bisher konnte sonst in keinster Weise auf den ATmega32u4 zugegriffen werden. Um sicherzugehen, dass der ATmega32u4 selber nicht kaputt ist, habe ich eine zweite separate Platine ausprobiert -> exakt gleiches Verhalten. Ich vermute, dass ich hier ein kleines Detail übersehen habe und dass die Lösung bzw. das Problem eigentlich offensichtlich sind. Daher hoffe ich, dass hier jemand mir den richtigen Anstoß geben kann. :) Es sieht für mich danach aus, als ob der ATmega32u4 den Pin für das SPI-Taktsignal selber aktiv treiben würde, obwohl sich dieser im Reset befindet... Fragen und hilfreiche Kommentare sind jederzeit gerne willkommen. Vielen Dank im Voraus.
Angehängte Dateien:
-
Schematic.png
31 KB -
SPI_Clock_Compare.png
4,4 KB -
SPI_Clock_vs_System_Clock.png
4,8 KB
Die Programmierung über USB ist fest verdrahtet und funktioniert in jedem Fall!! Was genau funktioniert nicht? Hast du das richtige Programm dazu verwendet?
Chris schrieb: > In dem gezeigten Ausschnitt des Schematics ... Das, was du in dem Bild zeigst, ist weit entfernt von einem Schematic. Wenn du mit den englischen Begriffen nicht vertraut bist, ist es deutlich weniger peinlich, sich in einem deutschen Forum auf die deutschen Bezeichnungen zu beschränken.
Chris schrieb: > SPI_Clock_Compare.png Wenn das ein 1 KHz Takt sein soll dann weist bereits die gelbe Kurvenform auf einen massiven Mess- und/oder Verdrahtungsfehler hin. Solche Überschwinger kann kein Digitalbaustein (bzw der AVR ISP mkII) alleine erzeugen. Da ist etwas grob im Argen, was, kann ich auch nicht aus der Entfernung sagen.
Chris schrieb: > Deutlich zu sehen ist, dass bei dem grünen Signal die Differenz zwischen > High und Low des SPI-Taktsignals nur ca. 1V beträgt und der ATmega32u4 > somit natürlich keine Flanken erkennt. Ich erinnere mich gerade an einen anderen Thread in diesen Tagen. Dort ist der Controller einfach falsch aufgelötet worden. Wenn der Controller zwei Marken auf dem Gehäuse hat kann man ihn leicht mit falscher Pinzuordnung auflöten was die "Triebkraft" des scheinbaren Clock-Pins erklären könnte.
Thomas W. schrieb: > Die Programmierung über USB ist fest verdrahtet und funktioniert > in > jedem Fall!! > > Was genau funktioniert nicht? > Hast du das richtige Programm dazu verwendet? Vielen Dank für die Antwort. Was genau funktioniert kann ich nicht sagen. Ich habe bereits Erfahrung sammeln können mit den Atmel USB DFU Bootloader und dem FLIP Tool. Was ich den ATmega32u4 per USB an den Rechner anschließe passiert nichts. Es gibt nicht mal die Meldung das ein USB-Gerät nicht erkannt wurde oder ähnliches. Ich habe die Vermutung, dass (glaube ich) die Datenleitungen nicht mit einem Pull-up nach VCC gezogen werden. Dies sollte der ATmega32u4 wenn Spannung am VBUS-Pin anliegt. Dies signalisiert einem USB-Host, dass ein Device angeschlossen wurde. Selbst dies ist nicht passiert Ich bin mir bei den Aussagen nicht ganz sicher, bitte korrigiert mich. Forist schrieb: > Chris schrieb: >> In dem gezeigten Ausschnitt des Schematics ... > > Das, was du in dem Bild zeigst, ist weit entfernt von einem Schematic. > Wenn du mit den englischen Begriffen nicht vertraut bist, ist es > deutlich weniger peinlich, sich in einem deutschen Forum auf die > deutschen Bezeichnungen zu beschränken. Ja, auch richtig. Ich hoffe der Beitrag ist trotzdem verständlich.... Fern Schätzer schrieb: > Chris schrieb: >> SPI_Clock_Compare.png > > Wenn das ein 1 KHz Takt sein soll dann weist bereits die gelbe > Kurvenform auf einen massiven Mess- und/oder Verdrahtungsfehler > hin. Solche Überschwinger kann kein Digitalbaustein (bzw > der AVR ISP mkII) alleine erzeugen. Da ist etwas grob im Argen, > was, kann ich auch nicht aus der Entfernung sagen. Das verwendete Oszilloskop ist sehr schlecht, daher sind die Kurvenformen mit Vorsicht zu genießen. Ich würde hier eher auf Messfehler bzw. schlechtes Messequipment setzen. Wenn jemand eine Empfehlung für ein Oszilloskop mit 2 Kanälen für >50 EUR hat, sind die sehr willkommen. :) Fern Schätzer schrieb: > Chris schrieb: >> Deutlich zu sehen ist, dass bei dem grünen Signal die Differenz zwischen >> High und Low des SPI-Taktsignals nur ca. 1V beträgt und der ATmega32u4 >> somit natürlich keine Flanken erkennt. > > Ich erinnere mich gerade an einen anderen Thread in diesen > Tagen. > > Dort ist der Controller einfach falsch aufgelötet worden. > Wenn der Controller zwei Marken auf dem Gehäuse hat kann > man ihn leicht mit falscher Pinzuordnung auflöten was die > "Triebkraft" des scheinbaren Clock-Pins erklären könnte. Habe ich eigentlich kontrolliert, werde aber nochmal genauer hinschauen. Man weiß ja nie. Wenn es daran lag, dann super. ich weiß dann zumindest was da los ist. :)
Chris schrieb: > Ich bin mir bei den Aussagen nicht ganz sicher, bitte korrigiert mich. Dagegen werde ich mir mit meiner Aussage zur falschen Pinzuordnung beim Auflöten immer sicherer. Soweit das aus dieser Entfernung und den mageren Informationen zu beurteilen ist. Schick doch einfach mal ein Foto vom eingelöteten Prozessor. Dann haben wir diesbezüglich schnell Klarheit.
Fern Schätzer schrieb: > Chris schrieb: >> Ich bin mir bei den Aussagen nicht ganz sicher, bitte korrigiert mich. > > Dagegen werde ich mir mit meiner Aussage zur falschen > Pinzuordnung beim Auflöten immer sicherer. Soweit das aus > dieser Entfernung und den mageren Informationen zu beurteilen > ist. > > Schick doch einfach mal ein Foto vom eingelöteten Prozessor. > Dann haben wir diesbezüglich schnell Klarheit. Ja, mache ich. Das Foto folgt heute Nachmittag dann. :)
Nachdem der Chip auf der von aussen kommenden SCLK Leitung beim falsch Einlöten immer einen Eingang anbietet (PD2, PC6 oder ARef) der jeweils keinen Pegel treiben kann bleibt eigentlich nur noch ein Chip Defekt übrig der durch Falschpolung entstanden ist, oder ein Kurzschluss der SCLK Leitung zu einem anderen Pin/Bauteil. Fern Schätzer schrieb: > Soweit das aus > dieser Entfernung und den mageren Informationen zu beurteilen > ist. "Unglücklich" wäre wenn der AVR ISP mkII defekt wäre und genau auf der SCLK Leitung es nicht mehr schafft vernünftige Pegel zu erzeugen. Als genial ist auch zu betrachten dass der Footprint im Layout- Programm keinerlei Orientierung zum Pin 1 anbietet. Oder hat jemand was gesehen was ich nicht gesehen habe?
Fern Schätzer schrieb: > Als genial ist auch zu betrachten dass der Footprint im Layout- > Programm keinerlei Orientierung zum Pin 1 anbietet. Oder hat > jemand was gesehen was ich nicht gesehen habe? Pin 1 des ATmega32u4 ist mit einem Kreis unten rechts im Footprint markiert.
Angehängte Dateien:
-
atmega42u4.jpg
420 KB
Hallo, hier ein Bild von einem atmega32u4 aus einer bestehenden Schaltung. Siehe: [1] https://www.ehajo.de/boards/91/atmega32u4-breakout-board [2] http://dokuwiki.ehajo.de/_media/artikel:lcd-adapter-004.pdf
Ich habe den Eindruck, dass Layout und Platinenbild nicht zusammenpassen.
DanVet schrieb: > Ich habe den Eindruck, dass Layout und Platinenbild nicht > zusammenpassen. Vollkommen richtig, das tun sie auch nicht. Das hochgeladene Platinenbild ist nur ein Beispiel. Ich werde ein passendes Bild nachher hochladen. :)
Angehängte Dateien:
-
Layout_vs_Board.PNG
910 KB
Fern Schätzer schrieb: > Chris schrieb: >> Ich bin mir bei den Aussagen nicht ganz sicher, bitte korrigiert mich. > > Dagegen werde ich mir mit meiner Aussage zur falschen > Pinzuordnung beim Auflöten immer sicherer. Soweit das aus > dieser Entfernung und den mageren Informationen zu beurteilen > ist. > > Schick doch einfach mal ein Foto vom eingelöteten Prozessor. > Dann haben wir diesbezüglich schnell Klarheit. So, im Anhang dieser Antwort nun das Bild von dem Layout und dem gelötetem Board. Angesteckt an die Pinleiste auf der linken Seite sind Logic Analyzer und weitere Gerätschaften zur Untersuchung. Ich hoffe die Qualität ist ausreichend. :)
Angehängte Dateien:
Als weiteres Beispiel zu dem Problem hier noch ein weiteres Bild. Dieses Mal die Aufzeichnung von dem, was ein Logic Analyzer sieht. Man erkennt sehr gut, dass der AVR ISP mkII die richtigen Daten ausgibt (Bytes 0xAC, 0x53, vgl. Datasheet ATmega32u4 Seite 364, Tabelle 28-16, Eintrag "Programming Enable", zweites Bild). Auch gut zu erkennen ist, dass das Reset-Signal standardmäßig 'high' (kein Reset) ist und der Programmer dieses entsprechend auf 'low' (Reset) zieht. Für diese Messung wurde zwischen AVR ISP mkII und ATmega32u4 ein Buffer geschaltet, um die Ausgabe des ISP-Clock-Signals entsprechend messen zu können. Bitte glaubt mir, dass das ISP-Clock-Signal sich nach dem Buffer genauso verhält wie in den Bildern aus dem initalen Beitrag dieses Themas. Jemand eine Idee was da los sein könnte?
Angehängte Dateien:
-
Suspicion.png
850 KB
Hallo Leute, ich habe eine Vermutung was das Problem sein könnte. Auf dem angehängten Bild zeigt der türkise Pfeil auf den ein verblasstes Dreieck der IC Beschriftung. Alle Bilder, die man von einem ATmega32u4 im TQFP44-Gehäuse findet enthalten dieses Dreieck nicht. Enthalten ist dieses Dreieck aber in der Beschriftung des TQFP44-ICs für den ATmega32 (ohne 'u4'). Meint ihr, dass könnte das Problem sein?
Da ist viel zu viel Rätselraten. Wenn du selbst schon nicht weißt, welcher µC bestückt ist....und dann diese unbestückten Bauteile und ungelöteten µC-Pins. Da kann ja alles mögliche schief laufen. Deinen Schaltplan haben wir bisher auch noch nicht gesehen :-(
Wie hast du die Platine gelötet? Vermutlich in einem selbstgebauten Reflow Ofen? Evtl. wurde der IC einer viel zu hohen Temperatur ausgesetzt.
Angehängte Dateien:
-
atmega42u4.jpg
420 KB
DanVet schrieb: > Ich schätze eher von Hand. Auf diesem Foto sieht das aber nicht danach aus.
Mick schrieb: > DanVet schrieb: >> Ich schätze eher von Hand. > > Auf diesem Foto sieht das aber nicht danach aus. Du solltest alle Beiträge lesen.
Mick schrieb: > Ooooh, die Forumpolizei ist wieder unterwegs :-) Was hat das jetzt mit dem Thema zu tun? schau mal hier Beitrag "Re: ATmega32u4 Programmierung - SPI Clock Verhalten merkwürdig"
Mick schrieb: > Wie hast du die Platine gelötet? Vermutlich in einem > selbstgebauten > Reflow Ofen? Evtl. wurde der IC einer viel zu hohen Temperatur > ausgesetzt. Der IC wurde von Hand gelötet. Gerätschaften, Temperatur, verwendete Materialen (Flussmittel, Lötzinn) kann ich gerne nennen, wenn es wichtig ist. Ich bin mir aber mittlerweile ziemlich sicher, dass dort der falsche IC eingesetzt wurde. Wie und warum der falsche IC in meine Hände gekommen ist, dass muss ich noch untersuchen. Ich bedanke mich sehr bei euch allen für die Beiträge und die Kommentare. Man lernt immer wieder etwas. :)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.