Erster Programmierversuch von atmega32u2 funktioniert nicht

Da der atmega32U2 mitsamt USB-bootloader ausgeliefert wird, der zu 
atmel-Flip passt, wird er normalerweise per USB-Anschluss mithilfe von 
Flip programmiert, ein MKII ist da nicht nötig. anstatt des 
ISP-Anschlusses muss dann halt die USB-Beschaltung vorhanden sein.

Fürs erste Programmieren per ISP braucht man:
alle Gnd-Anschlüsse, alle VCC und AVCC (komplette Spannungsversorgung)
Stützkondensator(en)
(ISP-Stecker):reset, mo, mi, sck,gnd

Mehr eigentlich nicht, da im Auslieferungszustand der interne 
RC-Oszillator läuft.

Aber, Vorsicht: beim Beschreiben per ISP wird im Allgemeinen der 
komplette Chip gelöscht. Dabei geht der auf dem Chip mitgelieferte 
USB-Bootloader verloren.

Peter R. schrieb:
> Da der atmega32U2 mitsamt USB-bootloader ausgeliefert wird, der zu
> atmel-Flip passt, wird er normalerweise per USB-Anschluss mithilfe von
> Flip programmiert, ein MKII ist da nicht nötig. anstatt des
> ISP-Anschlusses muss dann halt die USB-Beschaltung vorhanden sein.

Ach so. Das gibt bei mir ein paar Folgefragen:

Sind denn die Fuses so gesetzt, dass per ISP gar nicht programmiert 
werden kann?

Kann Flip ins Atmel Studio integriert werden?

Muss ich bei der Programmierung etwas beachten, wenn ein Boot Loader 
schon auf dem Chip ist?

Kann man einen Boot Loader nachträglich wieder auf den Chip pflanzen, 
falls man diesen gelöscht haben sollte?

Ich habe irgendwie den Eindruck, dass ich die Grundlagen zu Boot Loadern 
noch nicht ganz kappiert habe. Gibt es hier gute 
Beschreibungen/Einführungen/Howtos?

Danke und Gruss
Teddy

Peter R. schrieb:
> Mehr eigentlich nicht, da im Auslieferungszustand der interne
> RC-Oszillator läuft.

Falsch.

Der RC-Oszillator ist zu ungenau für die USB-Taktrate.  Da aber
gewollt ist, dass man ihn per USB und Bootloader betreiben kann,
kommen diese Controller voreingestellt auf externen Quarz daher.
Man muss also einen 8-MHz-Quarz (und die Lastkondensatoren) oder
ggf. einen entsprechenden Keramikresonator anschließen, wobei die
Genauigkeit der üblichen Keramikresonatoren eigentlich auch schon
zu schlecht ist für Fullspeed-USB.

Außerdem kommt er mit gesetzten Lockbits daher, damit man den
Bootloader nicht auslesen kann.  Man sollte also nicht erwarten,
dass man per ISP mehr als die Fuses und die Signature gelesen
bekommt, bevor man das erste chip erase ausgeführt hat.

Steht natürlich alles im Datenblatt …

Teddy M. schrieb:
> Kann man einen Boot Loader nachträglich wieder auf den Chip pflanzen,
> falls man diesen gelöscht haben sollte?

Ja, so man denn ein Hexfile dafür hat.  Der originale Atmel-Bootloader
ist meines Wissens nicht separat zu bekommen.  Allerdings gibt's bei
LUFA einen Rewrite dafür.

Jörg Wunsch schrieb:
> Der RC-Oszillator ist zu ungenau für die USB-Taktrate.  Da aber
> gewollt ist, dass man ihn per USB und Bootloader betreiben kann,
> kommen diese Controller voreingestellt auf externen Quarz daher.
> Man muss also einen 8-MHz-Quarz (und die Lastkondensatoren) oder
> ggf. einen entsprechenden Keramikresonator anschließen, wobei die
> Genauigkeit der üblichen Keramikresonatoren eigentlich auch schon
> zu schlecht ist für Fullspeed-USB.

Fast richtig.

8 oder 16MHz als Taktquelle.


> Sind denn die Fuses so gesetzt, dass per ISP gar nicht programmiert
> werden kann?

Nein, aber wenn du auch nur einmal per ISP programmierst oder auch nur 
die Fuses setzt, löscht er den Flash, also auch den Bootloader.
Der Atmel Bootloader ist closed source, die alternativen sind LUFA oder 
der vom Teensy (Soweit ich mich erinnere, ist da nicht der Atmel-loader 
drauf)

> Kann Flip ins Atmel Studio integriert werden?

Nicht wirklich, es ist ne eigenständige Applikation.

Andreas Kist schrieb:
>> Man muss also einen 8-MHz-Quarz (und die Lastkondensatoren) oder
>> ggf. einen entsprechenden Keramikresonator anschließen, ...
>
> Fast richtig.
>
> 8 oder 16MHz als Taktquelle.

Hatte ich auf die Schnelle nicht gefunden.  Gibt's da eine automatische
Erkennung?

Ich bin nun dabei die USB-Schnittstelle zu verkabeln. Dabei bin ich auf 
folgendes Hinderniss gestossen:

Ich habe vor die Schaltung wie in Figure 20-3 zu verwenden (Datenblatt 
atmega32u2, Seite 186).

UVss und Vss interpretiere ich noch als UGND und GND.

Bei UDM und UDP werde ich jedoch langsam stutzig. UDM interpretiere ich 
als D- und UDP als D+. Dann ist aber gegenüber dem controller das + und 
- vertauscht. Muss das so sein?

Danke und Gruss
Teddy

Jörg Wunsch schrieb:
>> 8 oder 16MHz als Taktquelle.
>
> Hatte ich auf die Schnelle nicht gefunden. Gibt's da eine automatische
> Erkennung?

Eeh, ich hab mich da etwas verlesen, das sind die maximalangaben.
Im Datenblatt steht bei 8.1.4, dass der USB-Teil nen eigenen PLL hat der 
bei 48 MHz rennt. Der Quarz, den man anschließt, ist nur für den Kern, 
da ists "egal", was du nimmst, es muss nur einer ran.

Teddy M. schrieb:
> Bei UDM und UDP werde ich jedoch langsam stutzig. UDM interpretiere ich
> als D- und UDP als D+. Dann ist aber gegenüber dem controller das + und
> - vertauscht. Muss das so sein?

Uff...Also ich hab mir damals einfach die Pinbelegung von einer USB-Mini 
Buchse angeguckt und dort dann D- an D- und D+ an D+ verkabelt.
Um das genauer sagen zu können, müsste ich mir meine Schaltpläne und 
Layouts angucken.

Andreas Kist schrieb:
> Der Quarz, den man anschließt, ist nur für den Kern,
> da ists "egal", was du nimmst, es muss nur einer ran.

Und womit wird dann die PLL gesteuert?

Ich weiß, dass bei ARMs durchaus eine Logik vorhanden ist, die beim
Start den Takt des angeschlossenen Quarzes bewertet und dann die
PLL-Einstellungen entsprechend vornimmt, sodass man wirklich mit
zwei verschiedenen Quarzfrequenzen arbeiten kann.  Mir ist aber
nichts bekannt, dass die kleinen AVRs ein ähnliches Feature hätten.

Prinzipiell könnte der DFU-Bootloader sowas natürlich implementieren,
aber das scheint alles nicht sehr gut dokumentiert.  Bis zum Beweis
des Gegenteils würde ich daher davon ausgehen, dass der Bootloader
nur mit einem angeschlossenen 8-MHz-Quarz läuft.

Andreas Kist schrieb:
> Uff...Also ich hab mir damals einfach die Pinbelegung von einer USB-Mini
> Buchse angeguckt und dort dann D- an D- und D+ an D+ verkabelt.
> Um das genauer sagen zu können, müsste ich mir meine Schaltpläne und
> Layouts angucken.

Ich wäre dir dankbar, wenn du schnell einen Blick auf deine Pläne werfen 
könntest.

Danke und Gruss
Teddy

Rene schrieb:
> ich denke, dass sollte Deine Frage beantworten:

Nö, hilft mir nicht weiter. Mir geht es nicht um die Stromversorgung des 
uC, sondern um den Anschluss von D+ und D- (bzw. was ist mit UDM und UDP 
gemeint?).

amateur schrieb:
> Es gibt ein paar Bibliotheken, die bei Verwendung eines Bootloaders mit
> eingebunden werden sollten. Sind beim Studio 6 bzw. ASF mit dabei.
> Irgendwas mit trampoline_xx.h bzw .asm.
> Was für spezielle Parameter hier benötigt werden weiß ich nicht. Hängt
> vom Bootloader bzw. dessen Größe ab.

Wenn ich mich gerade nicht irre, braucht man die nur, wenn man aus dem 
eigenen Code in den Bootloader hopsen will, aber wer braucht sowas 
schon?


Für den normalen Betrieb braucht man nur die üblichen(avr/io.h, 
util/delay.h, eventuell avr/interrupt.h). Zusätzlich noch avr/power.h, 
dann kann man z.B. den Prescaler von der Clock im laufenden Betrieb 
umstellen.