mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Matwei USBisp unter Linux: avrdude stk500_getsync(): not in sync: resp=0x15


Autor: Mirko Kaffka (mka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Mirko Kaffka (mka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mirko Kaffka (mka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Mirko Kaffka (mka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mirko Kaffka (mka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Mirko Kaffka (mka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mirko Kaffka (mka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.