Hallo, ich arbeite seit vielen Jahren mit diversen atmega und attiny Controllern. Diese flashe ich immer mit meinem USBASP und AVRDude. Das klappt auch immer perfekt. Nun wollte ich mal den atmega32u2 verwenden um native USB anstelle von VUSB nutzen zu können. So weit bin ich aber erst mal gar nicht gekommen. Das Problem beginnt mit den Fuses. Ich kann diese per AVRDude auslesen und sie stimmen auch mit den Default Werten des atmega32u2 überein. Dabei läuft der atmega32u2 ja eigentlich mit dem internen 8Mhz und geteiltem Takt, also auf 1Mhz. Hier war es schon mal komisch, dass er ohne externen Quarz nicht lesbar war. Ich dachte es würde so erst einmal ohne gehen. Aber nun gut, der ist dann eh vorhanden, da ich ja 16Mhz für USB benötige. Dafür muss dann ja auch die LFuse auf 0xFF gesetzt werden. Das schlug aber immer fehl. Dann bin ich auf einen Hinweis gekommen, dass ich -e mit angeben muss. Damit ging es dann auch. Die LFuse steht auf 0xFF. Ohne Quarz geht nun eh nichts mehr. :-) Aber warum musste ich den Flash leeren? Ist damit der Bootloader auch weg? Das wäre echt mega Mist. Denn den wollte ich später nutzen. Oder wird der Teil ausgelassen wenn die Einstellungen für die Bootsize usw. nicht geändert wurden. Ach ja, ansonsten ist er korrekt beschaltet mit Kondensatoren usw. Er läuft ja auch generell korrekt abgesehen von dem Problem des Setzens der LFuse. Fuses lesen: avrdude -c usbasp -p atmega32u2 -B 10 -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h Fuse schreiben (ging nicht, geht aber nach -e jetzt auch): avrdude -c usbasp -p m32u2 -B 10 -U lfuse:w:0xFF:m Fuse schreiben (geht): avrdude -c usbasp -p m32u2 -B 10 -e -U lfuse:w:0xFF:m Kann jemand meine vielen Fragen beantworten? Vielen Dank und Grüße aus dem Land der Rätsel.
:
Bearbeitet durch User
Da der Bootloader keine eigene Section im Flash hat, löscht ein Chip Erase den ganzen Flash (auch den Bootloader). Du könntest ja den Flash auslesen, dann hast du den Bootloader. Müsstest halt nach jedem Erase den Bootloader + FW flashen. Zu den Fuses und dem Qaurz kann ich spontan nichts sagen.
:
Bearbeitet durch User
Bist du dir sicher, dass die Teile ab Werk einen Bootloader vorprogrammiert haben? Meiner Erinnerung nach ist das nicht der Fall, und ich sehe auch nichts im Datenblatt. Wenn du erst einen chip erase brauchst, bevor du die Fuses ändern kannst, deutet das meiner Meinung darauf hin, dass der Chip nicht taufrisch ist. Wurde er aus vertrauenswürdiger Quelle gekauft? Könnte ja sein, er war einfach nur recycelt worden …
Jörg W. schrieb: > Bist du dir sicher, dass die Teile ab Werk einen Bootloader > vorprogrammiert haben? Nicht alle. Ansonsten: Haben sie sonst könnte man fabrikneue nicht mit Flip ansprechen. Kann man mit und ohne Bootloader bestellen, soweit mir bekannt. Default, war mit Bootloader. Zumindest damals, als das noch Atmel war. KA, ob sich das geändert hat.
Arduino F. schrieb: > Default, war mit Bootloader. Auch bei den ATmega…U? Mir ist so, als wäre das nur bei AT90USB… so gewesen. Aber definitive Unterlagen habe ich jetzt auch nicht gefunden auf die Schnelle.
Ich denke nicht, dass Reichelt "gebrauchte" verkauft. Und es war bei mehreren so. Hab es extra mit verschiedenen ausprobiert. Sicher bin ich mir mit dem Bootloader nicht. Andererseits wäre es schon komisch, wenn der Chip ohne wäre, die Fuses aber so gesetzt sind, als würde es einen geben. Das würde ja auch keinen Sinn ergeben. Ist beim atmega328p ja auch nicht der Fall. Wenn man da einen Bootloader verwenden möchte, muss man die Fuses dafür auch extra setzen. Bei Reichelt konnte ich das beim Bestellen nicht auswählen. Dementsprechend ging ich davon aus, dass der Bootloader vorhanden ist was zu den Fuses passen würde. Okay, der Bootloader ist also jetzt weg. Muss dann wohl entsprechend von einem weiteren neuen gelesen und gerettet werden um ihn nach dem setzen der Fuses wieder zu flashen. Also Download gibt es den nicht beim Hersteller?
Jörg W. schrieb: > Auch bei den ATmega…U? Mir ist so, als wäre das nur bei AT90USB… so Bei den 16U2 8U2 ist es ein fester Bootloader, Hardwarebootloader genannt, inc. zugehörigen HWB Pin. Beim 32U4 nennt es sich auch HWB, auch der hat den Pin. Nur ist beim 32U4 der Bootloader nicht fest in der Hardware, sondern im Flash, somit lösch- bzw. ersetzbar. Heiko schrieb: > Also Download gibt es den nicht beim > Hersteller? Habe auch mal gesucht. Und nicht gefunden. Ich verwende durchgängig Catarina. weil er funktioniert und bei der ArduinoIDE dabei ist.
:
Bearbeitet durch User
Arduino F. schrieb: > Bei den 16U2 8U2 ist es ein fester Bootloader, Hardwarebootloader > genannt, inc. zugehörigen HWB Pin. Ah OK. Irgendwie waren mir noch Unterschiede in Erinnerung. Heiko schrieb: > Ich denke nicht, dass Reichelt "gebrauchte" verkauft. Hmm, naja. https://www.richis-lab.de/OpampA16.htm "Der hier dokumentierte NE5532 wurde über Reichelt bezogen." (Spoiler: und hat sich nach dem Öffnen als Fälschung herausgestellt.)
Arduino F. schrieb: > Jörg W. schrieb: > > Habe auch mal gesucht. Und nicht gefunden. Ja, man findet den nur für den 32u4. Wenn er fest im Chip ist und nicht gelöscht wird, dann wäre das ja passend und ich hätte keinen Stress. Wie gesagt, sonst muss ich einen anderen mal auslesen. > > Ich verwende durchgängig Catarina. weil er funktioniert und bei der > ArduinoIDE dabei ist. Gut zu wissen. Allerdings verwende ich keine ArduinoIDE. Ich verwende immer nur den avr-gcc mit makefiles und den USBASP zum Flashen. Wollte immer bei allem unabhängig von den Arduino Sachen sein. Aber vielen Dank für die Tips schon mal :-)
32u2 oder 32u4? Fiel mir so beim durchblättern auf. Gibt es beide?
Angehängte Dateien:
-
32u2_bootloader.png
140 KB
also der 32u2 kann das per "option", steht so im Datenblatt. Hab eben selbst nachgesehen, ohne KI Schaut man länger ins Datenblatt, findet man keine Information darüber, ob sich der Bootlaoder bereits auf dem Chip befindet.
:
Bearbeitet durch User
Gab es da nicht ein Programm von Atmel: "Flip software for Windows 10 64-bit" Schon lange nichts mehr mit AVRs gemacht.
Beim 32u4 steht es explizit dabei:
1 | – Optional Boot Code Section with Independent Lock Bits |
2 | In-System Programming by On-chip Boot Program |
3 | True Read-While-Write Operation |
4 | Parts using external XTAL clock are pre-programed with a default USB bootloader |
Axel R. schrieb: > Beim 32u4 steht es explizit dabei: >
1 | > – Optional Boot Code Section with Independent Lock Bits |
2 | > In-System Programming by On-chip Boot Program |
3 | > True Read-While-Write Operation |
4 | > Parts using external XTAL clock are pre-programed with a default USB |
5 | > bootloader |
6 | > |
Okay, ich habe nun mal einen neuen Chip genommen und ausgelesen. Bei dem mit -e geleerten Chip sind die Lockbits 0xFF, also auch gelöscht. Ist ja auch so zu erwarten. Bei dem neuen ist es allerdings so, dass 0xec gesetzt ist. Ich vermute nun mal, dass ich die Fuses gar nicht modifizeren darf/muss um den 16Mhz Quarz zu verwenden. Deshalb funktioniert er wohl auch ohne Quarz frisch aus der Packung nicht. 5E => external 8Mhz- mit CKDIV8. Das ergibt dann wohl 2Mhz. Man sollte das Ding wohl so nehmen wie es aus der Packung kommt. Es sei denn man braucht den Bootloader nicht und will ihn ersetzen oder ganz losewerden. Auslesen ist wohl nicht möglich mit den Lockbits. Bleibt nur noch die Frage wie man an den originalen Bootloader kommt. Ich habe ihn echt nirgends als Hex oder Bin bei Microchip gefunden. Processing -U lfuse:r:-:h Reading lfuse memory ... Writing 1 byte to output file <stdout> 0x5e Processing -U hfuse:r:-:h Reading hfuse memory ... Writing 1 byte to output file <stdout> 0xd9 Processing -U efuse:r:-:h Reading efuse memory ... Writing 1 byte to output file <stdout> 0xf4 Reading lock memory ... Writing 1 byte to output file <stdout> 0xec
Heiko schrieb: > Ich verwende > immer nur den avr-gcc mit makefiles und den USBASP zum Flashen. Dann ist das ganze Gefasel über Bootloader komplett Sinnfrei! Einfach die Fuses richtig setzen und gut ist.
Arduino F. schrieb: > Heiko schrieb: >> Ich verwende >> immer nur den avr-gcc mit makefiles und den USBASP zum Flashen. > > Dann ist das ganze Gefasel über Bootloader komplett Sinnfrei! > Einfach die Fuses richtig setzen und gut ist. Ist es nicht, da ich den 32u2 verwenden möchte um mir den ISP auf dem finalen Layout zu ersparen, und auch das VUSB Geraffel braucht es dann nicht. Ich möchte einen USB fähigen Chip der sich ohne ISP also USBASP updaten lässt. Denn sonst hätte ich auch einen m328p mit VUSB und einem angepassten micronucleus bootloader verwenden können. Aber genau dafür ist der m32u2 ja gemacht!
Beitrag #8026814 wurde vom Autor gelöscht.
Heiko schrieb: > um mir den ISP auf dem finalen Layout zu ersparen Da sparst du dir ja ein Vermögen. Du wirst es nicht bereuen.
Die 8u2 bis 32u4 können alle optional mit USB-Bootloader bestellt werden. Außerdem besitzen sie jedoch alle andere Default-Fuseeinstellungen bezüglich Takt im Gegensatz zu anderen AVRs: Default Low Fuses 0x5E Low Power Crystal Oscillator 8.0 - 16.0MHz Ceramic resonator, slowly rising power 258 CK ; 14CK + 65 ms Und sie besitzen eine HWBE Fuse, welche programmed (0) ist. Der Oszillator muss also im Grundzustand verwendet werden. Heiko schrieb: > um mir den ISP auf dem finalen Layout zu ersparen Mit könntest Du Dir aber Probleme ersparen. Du musst ja nur die 4 Leitungen, +Ub und GND zugänglich machen (z.B. Testpads) und die HW so auslegen, dass sich ISP nicht mit Peripherie kloppt. Den Chip auszulöten, wenn Du den Bootloader zerschossen hast, ist zumindest keine gute Alternative. Gruß Jobst
:
Bearbeitet durch User
Habe gerade mal in meinen alten Beständen gewühlt … Das Atmel ›doc7618‹ ›USB DFU Bootloader Datasheet‹ beinhaltet eine Menge Informationen und auch sourcecode. Aber nur für die AT90USBxxx und die ATmega16/32U4. Man müsste die Unterschiede zwischen den U2 und den U4 klären.
Ja, vielen Dank! Das hatte ich auch gefunden. Mittlerweile bin ich offenbar auch an ein hex und bin File mit dem 32u2 Bootloader gekommen. Ich habe ihn geflashed und die Fuses wieder in den originalen Zustand versetzt. Ob das nun passt, werde ich dann sehen. Warte noch auf die 22Ohm Widerstände. Zum Glück ist das Ding nicht verlötet und steckt in einem Testsockel. Somit habe ich aktuell keine Probleme das Ding per ISP zu erreichen. Ich wollte das Thema ja erst mal testen. Und wenn das so klappt wie ich mir das vorstelle, dann kommt das überhaupt erst mal auf eine Platine. Ist quasi die Machbarkeitsstudie.
Heiko schrieb: > Warte noch auf die 22Ohm Widerstände. Sind das die Widerstände in den USB-Leitungen? Sollte auch für den ersten Test ohne funktionieren.
Jörg W. schrieb: > Heiko schrieb: >> Warte noch auf die 22Ohm Widerstände. > > Sind das die Widerstände in den USB-Leitungen? Sollte auch für den > ersten Test ohne funktionieren. Ja genau, dass sind die für D+ und D-. Hab nur 30Ohm da. Der Kondensator mit 1µF für UCAP fehlt leider auch noch. Ich hatte nur noch 10µF auf Lager Die sollten aber heute kommen. Dann bin ich mal gespannt was passiert.
So, ich habe nun 30Ohm verwendet. Der originale Bootloader welchen ich gefunden und wieder per ISP geflashed habe scheint soweit zu funktionieren. Er wird als USB Gerät korrekt erkannt. Bus 001 Device 117: ID 03eb:2ff0 Atmel Corp. atmega32u2 DFU bootloader Damit ist der Thread hier für mich gelöst. :-)
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.