Forum: Mikrocontroller und Digitale Elektronik ATmega32u4 Programmierung - SPI Clock Verhalten merkwürdig


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Chris (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas W. (diddl)


Bewertung
0 lesenswert
nicht lesenswert
Die Programmierung über USB ist fest verdrahtet und funktioniert in 
jedem Fall!!

Was genau funktioniert nicht?
Hast du das richtige Programm dazu verwendet?

von Forist (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Fern Schätzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Fern Schätzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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. :)

von Fern Schätzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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. :)

von Fern Schätzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Karl M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von DanVet (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe den Eindruck, dass Layout und Platinenbild nicht 
zusammenpassen.

von Chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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. :)

von Chris (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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. :)

von Chris (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

von Chris (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

von DanVet (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :-(

von Mick (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie hast du die Platine gelötet? Vermutlich in einem selbstgebauten 
Reflow Ofen? Evtl. wurde der IC einer viel zu hohen Temperatur 
ausgesetzt.

von DanVet (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mick schrieb:
> Wie hast du die Platine gelötet?

Ich schätze eher von Hand.

von Mick (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
DanVet schrieb:
> Ich schätze eher von Hand.

Auf diesem Foto sieht das aber nicht danach aus.

von DanVet (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Reto (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Kapp mal diese Zuleitung. Pin 42 Aref.

von Mick (Gast)


Bewertung
0 lesenswert
nicht lesenswert
DanVet schrieb:
> Du solltest alle Beiträge lesen.

Ooooh, die Forumpolizei ist wieder unterwegs :-)

von DanVet (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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"

von Chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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. :)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.