Forum: Mikrocontroller und Digitale Elektronik usbasp mit neuem atmega8 nicht mehr lauffähig


von Felix H. (masterq)


Lesenswert?

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!

von Sigint 112 (sigint)


Lesenswert?

Sicher, daß es der gleiche ATmega8-Typ ist? Es gibt ja mittlerweile 
mehrere Versionen, die sich ATmega8 schimpfen. (L,HVA,U, etc.)

von Vlad T. (vlad_tepesch)


Lesenswert?

ganz dumme frage:
hast du das Programm denn für die atmega48 neu übersetzt?

von Felix H. (masterq)


Lesenswert?

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

von Achim M. (minifloat)


Lesenswert?

Ich hab hier ein Mega48 von 0937, der rennt im Usbasp einwandfrei.
also generell geht es wohl mit den 48ern.
mfg mf

von Felix H. (masterq)


Lesenswert?

Weiß jemand vielleicht was die nummern genau zu bedeuten haben?

Grüße

Felix

von Mike (Gast)


Lesenswert?

Produktionsdatum: 27. Woche 2010

von Mike (Gast)


Lesenswert?

Hast Du auch die CKDIV8 Divide Clock by 8 -Fuse gesetzt?

von Felix H. (masterq)


Lesenswert?

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

von Helmut R. (helmut-stromer)


Lesenswert?

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

von Hubert G. (hubertg)


Lesenswert?

Hallo
Ich habe hier einen ATmega8-16PU Produktionsnummer 1045, dieser 
funktioniert mit dem AVR-USB-Lab einwandfrei.

von Felix H. (masterq)


Lesenswert?

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

von Helmut R. (helmut-stromer)


Angehängte Dateien:

Lesenswert?

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

von Felix H. (masterq)


Lesenswert?

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

von Bernhard M. (boregard)


Lesenswert?

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?

von Hubert G. (hubertg)


Lesenswert?

@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?

von Rubelus (Gast)


Lesenswert?

Ich habe hier übrigens den Atmega8-16PU mit Datum 1051 hier im Einsatz 
als USB AVR-Lab (also quasi gleich USBASP). Läuft tadellos!

von Felix H. (masterq)


Lesenswert?

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

von Felix H. (masterq)


Lesenswert?

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

von Rene K. (draconix)


Lesenswert?

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?

von Felix H. (masterq)


Lesenswert?

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

von Achim M. (minifloat)


Lesenswert?

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

von Marco S (Gast)


Lesenswert?

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.

von Felix H. (masterq)


Lesenswert?

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

von Marco S (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Felix H. (masterq)


Lesenswert?

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.

von holger (Gast)


Lesenswert?

>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;)

von Jay B. (jay_)


Lesenswert?

holger schrieb:
> Vollidiot;)

warum denn der smiley hinter deiner unterschrift?

von Helmut R. (helmut-stromer)


Lesenswert?

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

von Lars L. (vertigo)


Lesenswert?

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

Bitte 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
Noch kein Account? Hier anmelden.