Hallo zusammen,
ich habe mir 2 USBASP Programmer gebaut, und mir die Firmware auf einen
atmega8 gespielt, alles funktioniert hervorragend!
Jedoch habe ich mir jetzt einen zweiten atmega8 bespielt und auch ein
paar atmega48 probiert, jedoch sind beide Geräte mit den neuen uC's
nicht mehr lauffähig, sobald ich jedoch den alten atmega8 draufsetze ist
alles bestens. Ich wüsste einfach nicht mehr wo dran das noch liegen
kann. Habe an die Fuses gedacht in allen fällen, habe sogar mal die
Firmware und die Fuses aus dem alten atmega8 geladen und 1 zu 1 auf den
neuen gespielt.
Ich habe es an verschiedenen Computern probiert und die Hardware scheint
ja offensichtlich in Ordnung zu sein... Linux gibt mir beim anstecken
des usbasp folgende Fehlermeldung:
1
Nov 1 10:05:50 LapBox kernel: [220397.000058] usb 2-2: new low speed USB device using uhci_hcd and address 47
2
Nov 1 10:05:50 LapBox kernel: [220397.147757] usb 2-2: device descriptor read/all, error -71
3
Nov 1 10:05:50 LapBox kernel: [220397.260047] usb 2-2: new low speed USB device using uhci_hcd and address 48
4
Nov 1 10:05:50 LapBox kernel: [220397.411756] usb 2-2: device descriptor read/all, error -71
5
Nov 1 10:05:51 LapBox kernel: [220397.524050] usb 2-2: new low speed USB device using uhci_hcd and address 49
6
Nov 1 10:05:51 LapBox kernel: [220397.555756] usb 2-2: device descriptor read/8, error -71
7
Nov 1 10:05:51 LapBox kernel: [220397.683758] usb 2-2: device descriptor read/8, error -71
8
Nov 1 10:05:51 LapBox kernel: [220397.896059] usb 2-2: new low speed USB device using uhci_hcd and address 50
9
Nov 1 10:05:51 LapBox kernel: [220397.927765] usb 2-2: device descriptor read/8, error -71
10
Nov 1 10:05:51 LapBox kernel: [220398.055757] usb 2-2: device descriptor read/8, error -71
11
Nov 1 10:05:51 LapBox kernel: [220398.156065] hub 2-0:1.0: unable to enumerate USB device on port 2
Anzumerken ist vielleicht noch das ich die neuen AVR's zu einem späteren
Zeitpunkt gekauft habe!
Vielen dank für eure Hilfe!
Erst mal vielen dank für die antworten,
neu übersetzt klar! Habe auch den vorgekauten code probiert, und ältere
Versionen... Ohne Erfolg :-(
Ob es genau der gleiche uC ist weiß ich nicht genau,
der funktionierende ist beschriftet mit:
0945G
ATMEGA8-16PU
Die nicht funktionierenden mit:
1031
ATMEGA8-16PU
und
1027
ATMEGA48-20PU
und
1026
ATMEGA48-20PU
Genaueres weiß ich leider nicht...
Grüße
Felix
Ich habe die Fuse Einstellungen vom usbasp für den atmega48 direkt aus
der Makefile übernommen. Und gehe davon aus das die fuse bits richtig
gesetzt sind. Einmal habe ich es auch manuell gemacht, und da waren sie
auf jedenfalls richtig, das weiß ich genau weil ich auch eine Uhr drauf
laufen hatte.
Ich habe mir einen atmega8 aus einer anderen Quelle besorgt mit dem
läuft es wieder hervorragend.
Die anderen waren von Pollin.
Auch wenn ich das Problem jetzt erst mal gelöst habe, wäre ich immer
noch daran interessiert wo dran das liegen könnte, also wenn jemand noch
eine konstruktive Idee hat, gerne Posten ich werde es testen.
Grüße
Felix
Hallo,
gibt es schon eine Lösung mit den neuen Atmega8-16PU oder Atmega8A?
Hab das selbe Problem mit der Ware ab 2010. Meine Produktionsnummern ab
1045 funktionieren auch nicht.
Gruß Helmut
Hallo, ich habe das Problem auch nicht lösen können, ich habe ein paar
von meinen alten Atmega8 wiederbelebt, und deshalb ist es nicht mehr so
relevant für mich. Aber bei meinen Fuses bin ich mir auch sehr sicher
gewesen, da ich die Fuseseinstellung direkt auf die neuen Devices
übertragen habe, und auch nochmal überprüft.
Ziemlich doof, allerdings habe ich es auch nochmal mit einem SMD atmega8
probiert, welcher so, meine ich neuer war, was ebenfalls erfolgreich
verlaufen ist.
Grüße
Felix
Hallo AVR Gemeinde,
Hab den Fehler gefunden!
bei den neuen Atmega8-16PU oder Atmega48-20PU liegt der LO-Pegel der
Pins um 0.3V höher als bei den alten.
Der USB Port kann somit das LO Signal nicht mehr eindeutig
identifizieren.
Ich hab mit einer Universal Diode die Programmer Masse gegenüber der USB
Masse um 0.5V nach unten gezogen und der Programmer wird wieder
wunderbar erkannt.
Hab die Änderug im Schaltplan gekennzeichnet und angehängt.
Gruß Helmut
Schön zu hören das jemand weiß wo das Problem liegt.
Ich habe es jedoch nicht ganz verstanden, ich dachte der LO Pegel am
Ausgang des uCs wäre immer 0V...
Wärst du bereit noch ein paar Worte dazu zu sagen?
Grüße Felix
Müssten dann D1 und D2 nicht auch auf den Masse Anschluss vom USB Port
gehen, anstatt auf Schaltungsmasse?
Und liegt die Schaltungsmasse so nicht 0.5 V über USB Masse?
@Helmut R.
Es ist gut wenn du eine Lösung für dich gefunden hast.
Das AVR-USB-Lab ist hardwaremässig nahezu ident mit dem USBASP,
funktioniert allerding auch mit den neuen ATmega8-16 Prod.1045
einwandfrei.
Was mich bei meinen Tests allerdings überrascht hat, ist, das sich
dieser Kontroller bei den paar Tests genau so verhält wie ein Mega8A.
Wenn ich den AVR-Transistortester (aus der Artikelsammlung) drauf
spiele, muss ich die selben Parameter ändern wie beim Mega8A um ein
vernünftiges Meßergebnis zu erzielen.
Der Ruhestromverbrauch ist gleich dem Mega8A.
Das Resetverhalten, hier beschrieben
Beitrag "ATmega8A Hoher Stromverbrauch nach Reset" ist ebenfalls gleich.
Es würde mich nicht wundern wenn es noch ein paar ausreisser in den
elektrischen Daten geben würde.
Oder irrtümlich nur falsch gelabeld?
Ich kann keinen Ausschlaggebenden unterschied vom usbasp zum avr usblab
feststellen. Hat vielleicht jemand eine Idee, wie es zu diesem
unterschiedlichen verhalten kommen kann?
Grüße
Felix
Habe feststellen können, warum die neuen atmegas nicht funktioniert
haben, letzten Endes war es wirklich ein Pegel Problem.
Aber nicht zuletzt ausgelöst durch die Pegel Wandler(z-Dioden).
Imtuitiv habe ich mal meine 0,5W 3,6V z-Dioden durch kleinere
ausgetauscht, und siehe da, der usbasp nimmt jetzt auch die neuen
Controller.
Es wäre interessant zu wissen welche z-Dioden, die anderen benutzt haben
bei denen es nicht funktioniert hat...
Grüße
Felix
Felix H. schrieb:> Es wäre interessant zu wissen welche z-Dioden, die anderen benutzt haben> bei denen es nicht funktioniert hat...
Das ist natürlich eine Möglichkeit! Ich nutze 0,5W 3,3 Zener und damit
laufen auch die neueren ATmega8 - Müsste echtmal die die 3,3 durch 3,6
Zener ersetzen und schauen was sich dann an den Pegeln tut.
Wie bist du überhaupt darauf gekommen das er ihn nicht mehr als High
definieren kann?! Oszi dran gehabt?
Ne, habe ich nicht nachgemessen, habe nur ein analoges Oszilloskop. Und
den asp noch umzuprogramieren schien mir den Aufwand nicht zu
rechtfertigen. Denn das klappt ja nur gut mit wiederholenden Signalen,
ich habe den Schaltplan mit dem des avr labs verglichen und konnte
keinen ausschlaggebenden unterschied feststellen, und dann habe ich
nochmal einen neuen gebaut mit den kleineren z-dioden, als feststellte
das dieser auch mit den neuen Chips funktioniert und ich sonnst nur ein
unwesentlichen Widerstände variiert habe, musste es ja an den z-dioden
liegen, anschließend habe ich noch die z-dioden meines älteren usb asp
ausgetauscht und siehe da es funktioniert.
Grüße
Felix
Sehe gerade: Bei mir sind BZX55B-3V6 Zener drin.
Außerdem habe ich von ATmega48-Portpin zu USB bzw. Zenerdioden jeweils
56Ω statt 68Ω.
Das scheint den Pegel genug anzuheben.
Vllt. ist es einfacher, die Mühle auf 3,3V, 5V-tolerant umzubauen.
Also LM317 verwenden und Widerstände in die Datenleitungen(Zumindest in
alle Leitungen von Target zu Programmer, also in die MISO-Leitung).
mfg mf
Habe 68R mit 3.6V Zener 0.5W, sowie blauen 3mm LED probiert. Bei beiden
Lösungen lag der vom AVR generierte Highpegel bei ca 3.9 V, Lowpegel um
0V. Getestet an drei verschiedenen PCs bin ich froh, dass es so
funktioniert. Da kann nämlich auch der PC streiken. Vielleicht haben ja
die neueren AVR entsprechende Power, um die Nennspannung von 3.3V am
USB-Bus signifikant zu überschreiten. Dann würde ich es eher mal mit 75R
versuchen.
Hehe, ich habe heute mittels Material Mangel einen USBasp mit 82 Ohm
Widerständen auf Data+ und Data- Gebaut, dieses Model war nicht
lauffähig, erst nach dem ich die Widerstände verringert hatte wurde er
wieder einwandfrei vom Betriebssystem erkannt.
Ich glaube bei mir ist die Problematik eher das der uC den Highpegel der
USB Schnittstelle nicht erkennen kann, wobei 3,9 V (Wo hast du gemessen
Marco S Controller nach oder vor dem Widerstand?) ja schon reichen
sollten...
Jedoch kann ich mir anders nicht erklären, warum ein größerer Widerstand
nicht funktionieren sollte, ein kleinerer jedoch schon.
@Marco S
Falls du an der USB-schnittstelle gemessen hast, also vor dem Widerstand
würde ich mich freuen wenn du die Messungen noch einmal hinter dem
Widerstand am uC wiederholen könntest.
Grüße
Felix
DPlus zeigt vor/hinter 68R.
DMinusZener: Man erkennt sehr schön die 3.3V vom PC, mehr als 3.3V vom
AVR und Leerlauf, gebildet durch Pullup AVR und Pulldown PC.
DMinusAVR lässt erkennen, dass 0.6*Vcc für Vih erfüllt ist.
Vielen dank,
das sehe ich auch so,
meinst du es wäre ein Problem wenn der Leerlauf vom avr als low gedeutet
würde?
(sicht auf data-)
Also auf deinem Auszug kommt beide ja immer nach dem highlevel in dem
leerlauf, und der PC zieht den dataline runter wenn er etwas zumelden
hat, und der controller zieht sie auf high, was aber auch damit zu tuen
haben kann das der avr pin erstmal high ist wenn der avr pin als Ausgang
definiert wird... Und der PC erst reagiert wenn er auf low gezogen
wurde... (Was ja aber eigentlich blöde wäre weil dann hat der PC ja mehr
Zeit zu denken das die dataline noch frei ist -> Kollision) Habe leider
immer noch keine Zeit gehabt den Code zu lesen.
Ich glaube es könnte ein Problem sein, da ich annehme das der Controller
weiter Daten entgegen nehmen will solange data- auf low ist...
Jedoch dürfte das Problem ja nicht auftreten soweit der PC von high auf
idle wechselt, denn solange, dass der Fall ist sollte er die < 3V im
Idle-Modus ja weiterhin als high werten.
Zu beachten ist das die USB Schnittstelle stets mit Spannungsdifferenzen
arbeitet, also ohne GND.
was der avr ja direkt nicht kann, und dies deshalb Software technisch
gelöst werden muss.
Also wenn ich alles richtig verstanden habe (Meine ersten erfahrung mit
der USB Schnittstelle) sollte dies immer gelten:
d+ = ~(d-)
~ = nicht = invertiert
Es wäre vielleicht nochmal interessant data+ und data- mit der gleichen
zeit Achse zu sehen.
Grüße
Felix
PS:
@Marco S.
Schade das du keinen usbasp hast der nicht funktioniert und ich kein
digitales Oszilloskop.
>Zu beachten ist das die USB Schnittstelle stets mit Spannungsdifferenzen>arbeitet, also ohne GND.
Dann schneid mal die GND Leitung von deinem USB Stick durch.
Du wirst dich wundern warum er nicht mehr funktioniert.
Vollidiot;)
Hallo Holger,
schon mal was von Symmetrischer Datenübertragung gehört?
Wird nicht nur in der Bühnentechnik ( Brummschleifen ) sondern auch in
der Datentechnik wie LAN und USB verwendet.
Bei einer Symmetrischen Datenleitung ist die GND wirklich nicht wichtig.
Für die 5V Versorgung des Sticks jedoch wichtig.
Nachzulesen unter: http://de.wikipedia.org/wiki/USB
Gruß Helmut
Hallo,
hatte vor 1Monat mit V-USB und nem mega8 begonnen und jetzt endlich habe
ich diesen Beitrag entdeckt. Ich hatte genau das selbe Problem wie
Helmut R. Gut das hier die Fehlermeldung drinne war die Linux
ausgespuckt hat :-D
Überlege mir das gerade ins Wiki reinzustellen glaube das könnte noch
einigen so gehen wie mir.
Gruß Lars