Hallo,
ich habe hier einen Matwei USBisp v1.0 und bekomme ihn unter Gentoo
Linux auf meinem Desktop-PC einfach nicht zum Laufen. An meinem Notebook
unter FreeBSD 7 funktioniert das Teil aber problemlos. Als Programm
nutze ich auf beiden Rechnern avrdude 5.5. So langsam gehen mir die
Ideen aus, wie ich den Fehler weiter einkreisen kann.
Wenn ich avrdude mit 4* -v die Kommunikation mit dem Programmer
mitloggen lasse, kommt das dabei raus:
~ $ avrdude -P /dev/ttyUSB0 -c stk500v1 -p m16 -t -v -v -v -v
avrdude: Version 5.5, compiled on Oct 19 2008 at 11:19:21
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
System wide configuration file is "/usr/local/etc/avrdude.conf"
User configuration file is "/home/mirko/.avrduderc"
Using Port : /dev/ttyUSB0
Using Programmer : stk500v1
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [15]
avrdude: stk500_getsync(): not in sync: resp=0x15
avrdude: Send: Q [51] [20]
avrdude: Recv: . [15]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [15]
avrdude: stk500_getsync(): not in sync: resp=0x15
avrdude done. Thank you.
Unter FreeBSD kommt statt der 0x15 ein 0x14 0x10 zurück, was dann
funktioniert. In der Firmware ist 0x15 als Resp_STK_NOSYNC definiert und
wird gesendet wenn die "state machine" des Programmers ein Byte vom PC
empfangen hat, mit dem sie nichts anfangen kann. Klingt für mich nach
einem falschen Byte auf der "Leitung".
Schließe ich einen USB/Seriell Adapter mit FT232 statt des USBisp an,
sehe ich dass wirklich nur 0x30 0x20 von avrdude gesendet werden. Wenn
ich im Terminalprogramm dann schnell genug mit ^T^P antworte (0x14
0x10), meint avrdude, einen Programmer gefunden zu haben und macht
weiter. USB-Controller, Linux-Treiber und avrdude scheinen also ok zu
sein.
Da der PC nur 4,8V am USB gebracht hat, habe ich einen USB-Hub mit
externem Netzteil dazwischen gehängt. Damit wird der USBisp nun auch mit
5V versorgt (nachgemessen 4,94V). Trotzdem kommt der USBisp hier nicht
'in sync'.
Was kann denn das noch sein?
Etwas ratlos,
Mirko
PS: Als Firmware läuft mittlerweile die app_v2, wobei ich aber (unter
FreeBSD) als avrdude-Option trotzdem -c STK500v1 angeben muss. Ich
dachte die app_v2 implementiert das STK500v2 Protokoll und das kann man
dann mit avrdude -c STK500v2 nutzen?
Ich habe auf dem Desktop-PC testweise auch mal FreeBSD 7 installiert - in der 32Bit- sowie in der 64Bit-Variante. Damit funktioniert avrdude mit dem USBisp. Es scheint also ein Linux-Problem zu sein (Kernel 2.6.21) und ich brauch das hier gerade unter Linux. > Als Firmware läuft mittlerweile die app_v2, wobei ich aber (unter > FreeBSD) als avrdude-Option trotzdem -c STK500v1 angeben muss. Ich > dachte die app_v2 implementiert das STK500v2 Protokoll und das kann man > dann mit avrdude -c STK500v2 nutzen? Korrektur: Die Firmware läßt sich über den Bootloader nicht updaten. Die rote und grüne LED blinken dabei zwar sehr schnell aber hinterher ist die neue Firmware nicht drauf. Ein Verify scheint der Bootloader ja ohnehin nicht zu können. Ich hatte mal ein Testprogramm geflasht, was eine LED blinken lässt, der USBisp redete danach aber immernoch STK500v1 Protokoll.
Mirko Kaffka wrote: > Korrektur: Die Firmware läßt sich über den Bootloader nicht updaten. Die > rote und grüne LED blinken dabei zwar sehr schnell aber hinterher ist > die neue Firmware nicht drauf. Seltsam. Eine v2-Firmware sollte das Problem aber auf jeden Fall aus der Welt schaffen, da dort das serielle Framing viel aufwändiger gelöst ist, sodass ein einzelnes Schrottzeichen nicht die komplette Synchronisation außer Tritt bringt. Kannst du denn eventuell die v2-Firmware über ISP statt über den Bootloader draufbringen? Vielleicht hast du ja die Bootloader-Fuses falsch gesetzt, sodass der nicht schreiben darf? (Dafür brauchst du ja aber auch wieder das externe ISP.) Interessant wäre natürlich trotzdem noch, was denn das Linux da als erstes Zeichen hinpumpt. Vielleicht steht ja irgendwo die Schnitt- stelle auf Xon/Xoff-Flowcontrol, und will dann als erstes ein ^Q senden? Was mich auch wundert ist, dass die Retry-Logik von AVRDUDE nicht so funktioniert, wie ich das erwartet hätte. Dafür gibt's ja eigentlich dieses GET_SYNC, damit man das ein paarmal wiederholt, bis sich beide Seiten ,,gefunden'' haben. Hast du eventuell einen separaten Computer, auf dem du einen seriellen Sniffer laufen lassen kannst? Unter FreeBSD kannst du dir dafür /usr/ports/comms/snooper mal ansehen. Das ist ein ,,aktiver'' Sniffer, d. h. er transportiert die Daten per Software zwischen zwei RS-232-Schnittstellen und zeichnet sie dabei auf.
> Kannst du denn eventuell die > v2-Firmware über ISP statt über den Bootloader draufbringen? Das war auch mein nächster Gedanke, ist nur etwas aufwändiger, da ich nur noch einen Parallelport-Programmer habe und der einzige Parallelport an meinem alten Rechner ist, den ich dazu erst wieder in Betrieb nehmen muss. > Vielleicht hast du ja die Bootloader-Fuses falsch gesetzt, sodass > der nicht schreiben darf? (Dafür brauchst du ja aber auch wieder > das externe ISP.) Schon möglich, ich werde das mal prüfen. > Interessant wäre natürlich trotzdem noch, was denn das Linux da als > erstes Zeichen hinpumpt. Vielleicht steht ja irgendwo die Schnitt- > stelle auf Xon/Xoff-Flowcontrol, und will dann als erstes ein ^Q > senden? Genau dazu wollte ich Deine Blink-Applikation flashen, die jedes Zeichen wieder zurück sendet. Mit avrdude -v -v -v -v ... müsste dann ja zu sehen sein was da kommt. > Hast du eventuell einen separaten Computer, auf dem du einen seriellen > Sniffer laufen lassen kannst? Um zu sehen, was als erstes Zeichen gesendet wird? Das hatte ich mit einem USB/Seriell-Wandler schon probiert (avrdude auf /dev/ttyUSB0 und an der RS232-Seite des Adapters einen Rechner mit kermit). Im kermit kommt ganz sauber nur 0x30 0x20 an. Um eventuelle nicht druckbare Zeichen zu sehen, hatte ich kermit mit strace laufen und mir dann angesehen, was der read-Call geliefert hat. Bin mir jetzt aber nicht ganz sicher, ob ich Hardware Flow Control extra eingeschaltet habe. Ich werde mich erstmal um die Firmware kümmern...
Hallo Jörg,
habe nun Dein Testprogramm auf dem USBisp, das alle Zeichen wieder
zurück sendet. Als erstes Zeichen kommt ein 0x09. Hier mal der gesamte
Aufruf:
~ $ avrdude -P /dev/ttyUSB0 -p m8 -t -v -v -v -v
[...]
Using Port : /dev/ttyUSB0
Using Programmer : stk500v1
drain><drain
avrdude: Send: 0 [30] [20]
drain>09 30 20 <drain
avrdude: Send: 0 [30] [20]
drain>09 30 20 <drain
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [09]
avrdude: stk500_getsync(): not in sync: resp=0x09
drain>30 20 <drain
avrdude: Send: Q [51] [20]
avrdude: Recv: . [09]
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x09
avrdude done. Thank you.
Die Firmware app_v2.hex habe ich auch mal geflasht, die reagiert über
USB allerdings gar nicht, der USBisp antwortet mit keinem Byte. Habe
auch gerade nochmal die Schaltpläne von v1 und v2 verglichen, da ich ja
eine v1 Platine habe: der FT245 ist da identisch an den ATmega8
angeschlossen.
> Die Firmware app_v2.hex habe ich auch mal geflasht, die reagiert über > USB allerdings gar nicht... Kein Wunder, wenn ich die app_v2 über den Bootloader programmiere, bekomme ich einen verification error: avrdude: verification error, first mismatch at byte 0x003b 0xe0 != 0x19 Danach habe ich sie über den Parallelport-Programmer geladen aber durch das chip erase wahrscheinlich den Bootloader gelöscht. Das Lock Bit Byte ist übrigens 0x3f, also "No restrictions for SPM or LPM accessing the Application section." und ebenso für die Boot section. So, habe alles korigiert, antwortet aber trotzdem nicht mit der app_v2. Das app.hex antwortet dagegen, kommt aber wieder nicht in sync.
So, erledigt aber nicht restlos geklärt: die app_v2 läuft nun unter Linux. Ich hatte zuletzt beim avrdude-Aufruf keinen Programmer angegeben (-c) und in der .avrduderc stand noch default_programmer = "stk500v1"; Damit antwortet die app_v2 Firmware gar nicht erst. Ungeklärt ist, warum die erste Version (usbisp_27_11_06.zip bin/app.hex) unter FreeBSD 7 funktioniert, unter Linux dagegen nicht, weil der ATmega8 ein 0x09 über den FT245 empfängt, das avrdude gar nicht gesendet hat.
Mirko Kaffka wrote: > Ungeklärt ist, warum die erste Version (usbisp_27_11_06.zip bin/app.hex) > unter FreeBSD 7 funktioniert, unter Linux dagegen nicht, weil der > ATmega8 ein 0x09 über den FT245 empfängt, das avrdude gar nicht gesendet > hat. Ja, das ist mir auch unklar, zumal sie ja ein USB-seriell-Adapter offensichtlich nicht sieht. War das auch einer auf FT232-Basis, d.h. der gleiche Treiber? Was mir auch unklar ist, ist warum die Resynchronisation von AVRDUDE nicht funktioniert. Aber schön, dass du das Teil damit erstmal wieder benutzen kannst.
> Ja, das ist mir auch unklar, zumal sie ja ein USB-seriell-Adapter > offensichtlich nicht sieht. War das auch einer auf FT232-Basis, d.h. > der gleiche Treiber? Ja, war es. Ich habe gestern noch leihweise einen baugleichen USBisp bekommen. Der lässt sich über den Bootloader wie erwartet programmieren und bringt mit der app.hex (v1) auch nicht das 0x09 Byte. Mit der app_v2.hex läuft er auch anstandslos. Vielleicht hat der FT245 auf meiner Platine einen Treffer. Manchmal hängt das lsusb-Kommando (listet angeschlossene USB Geräte) auch und bringt erst dann den Output, wenn ich den Programmer vom USB abziehe. Das Problem habe ich allerdings nur über den externen USB-Hub, nicht wenn ich ihn direkt an den Rechner stecke. > Was mir auch unklar ist, ist warum die Resynchronisation von AVRDUDE > nicht funktioniert. Was ich gesehen habe ist, dass das 0x09 Byte nicht nur einmal am Anfang kommt, sondern immer, wenn die 0x30 0x20 geschickt wurde. Da hilft auch ein anfängliches drain der Schnittstelle nichts, weil das "Schrott-Byte" erst durch das Senden der Daten auftritt.
Mirko Kaffka wrote: > Vielleicht hat der FT245 auf meiner Platine einen Treffer. Das wäre natürlich eine, wenn auch etwas ungewöhnliche, Erklärung. Vielleicht ist ja auch ein Abblockkondensator taub oder sowas? > Manchmal > hängt das lsusb-Kommando (listet angeschlossene USB Geräte) auch und > bringt erst dann den Output, wenn ich den Programmer vom USB abziehe. Das Problem scheint Linux zuweilen mal zu haben, wenn sich ein USB-Gerät daneben benimmt. Ich habe @work kürzlich Firmware für AT90USB1287 schreiben müssen, wobei man sich natürlich schon auch mal mit all dem Kram so vertut, dass sich das Gerät ("function" im USB-Jargon) daneben benimmt. Es hat mehr als einen unfreiwilligen Reboot des Linux-Laborrechners bedurft in derartigen Situationen. Interessanter Weise hat der USB-Stack auf meinem alten FreeBSD- Laptop (noch ein 6.x) damit viel weniger Huddeleien gehabt. Der rannte dann sauber in einen Timeout und hat den jeweiligen Port außer Betrieb genommen, ohne das gesamte System zum Stillstand zu bringen. > Das Problem habe ich allerdings nur über den externen USB-Hub, nicht > wenn ich ihn direkt an den Rechner stecke. Ich kann/will hier die USB-Hubs auch nicht ausschließen, kann sein, dass die nur Mift sind. Kann aber auch sein, dass der Linux-Hub-Code da irgendeine Klemmneigung hat. >> Was mir auch unklar ist, ist warum die Resynchronisation von AVRDUDE >> nicht funktioniert. > Was ich gesehen habe ist, dass das 0x09 Byte nicht nur einmal am Anfang > kommt, sondern immer, wenn die 0x30 0x20 geschickt wurde. Gut, dann ist das natürlich erklärlich.
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.