DIAMEX-AVR-USB timeouts mit avrdude auf FreeBSD

[Raba X. (raba_x)]

Hallo AVR-Freaks,

ich bin gerade dabei meine ersten MCUs zu fusen/flashen.

Mit dem Aufruf

avrdude -c stk500v2 -p t85 -P /dev/cuau1 -t -v -i 10

bekomme ich massenweise solche timeouts

avrdude: stk500v2_ReceiveMessage(): timeout

Einfügen einer Wartezeit (-i 10), wie hier beschrieben:
AVRDUDE,
hat die Fehlermeldungen etwas reduziert (kein Unterschied mit -i 90).
Andere Beiträge beziehen sich auf nicht-unix oder andere IDEs, bzw. 
haben mir keine konkreten Handlungstip gegeben.

Im Anhang sind USB-Parameter und avrdude-Protokoll dargestellt.

Was kann ich noch testen, um den Fehler einzukreisen?

Kann es sein, dass der DIAMEX-Stick hinüber ist, oder ist das mit dem 
Protokoll eher unwahrscheinlich?

Falls ich einen neuen brauche oder dieser nix taugt, mit welchem 
lieferbaren USB-Gerät für avrdude würde ich am besten fahren?

Danke für Eure Zeit, raba_x

[Jim M. (turboj)]

Falscher Programmer Typ.

Der möchte als -c avrispmkII -p USB angesprochen werden AFAIK.

[c-hater (Gast)]

Jim M. schrieb:
> Falscher Programmer Typ.
>
> Der möchte als -c avrispmkII -p USB angesprochen werden AFAIK.

Wenne es um diesen Stick hier geht (Beispiellink, gibt's auch woanders 
zu kaufen):

https://www.reichelt.de/programmer-f-avr-stk500-atmega-attiny-at90-diamex-usb-isp-p110344.html

dann ist stk500V2 absolut richtig. Das und nix anderes will der und 
braucht der.

@TO:
Versuch mal -b10 als Parameter. Wenn's damit problemlos funktioniert 
(wird es sehr wahrscheinlich), kannst du die Zahl verkleinern, bis es 
nicht mehr funktioniert. Dann wieder ein's rauf und du hast die optimale 
Bitrate für dein Target gefunden.
Darum geht es nämlich: Bitrate zwischen Programmer und Target. Ist die 
knapp zu hoch, versteht das Target mal, was man von ihm will, mal nicht. 
Antwortet also mal und mal nicht. Und genau das erzeugt diese netten, 
scheinbar zufälligen Timeouts.

[Raba X. (raba_x)]

Jim M. schrieb:
> Falscher Programmer Typ.
>
> Der möchte als -c avrispmkII -p USB angesprochen werden AFAIK.

Hersteller sagt 'stk500v2'.

[Raba X. (raba_x)]

c-hater schrieb:
> Jim M. schrieb:
> 
https://www.reichelt.de/programmer-f-avr-stk500-atmega-attiny-at90-diamex-usb-isp-p110344.html

Ja.
>
> dann ist stk500V2 absolut richtig. Das und nix anderes will der und
> braucht der.
>
> @TO:
> Versuch mal -b10 als Parameter. Wenn's damit problemlos funktioniert
> (wird es sehr wahrscheinlich), kannst du die Zahl verkleinern, bis es
> nicht mehr funktioniert. Dann wieder ein's rauf und du hast die optimale
> Bitrate für dein Target gefunden.
> Darum geht es nämlich: Bitrate zwischen Programmer und Target. Ist die
> knapp zu hoch, versteht das Target mal, was man von ihm will, mal nicht.
> Antwortet also mal und mal nicht. Und genau das erzeugt diese netten,
> scheinbar zufälligen Timeouts.

Leider:

root@home2l:/ #  avrdude -c stk500v2 -p t85 -P /dev/cuau0 -t -vvv -b 10 -i 90

avrdude: Version 6.4
         Copyright (c) Brian Dean, http://www.bdmicro.com/
         Copyright (c) Joerg Wunsch

         System wide configuration file is "/usr/local/etc/avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cuau0
         Using Programmer              : stk500v2
         Overriding Baud Rate          : 10
         Setting isp clock delay        :  90
avrdude: serial_baud_lookup(): Using non-standard baud rate: 10avrdude: ser_recv(): programmer is not responding
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: ser_recv(): programmer is not responding
avrdude: stk500v2_ReceiveMessage(): timeout

-b bewirkt noch weniger als -i .

raba X

[c-hater (Gast)]

Raba X. schrieb:

> avrdude: serial_baud_lookup(): Using non-standard baud rate: 10avrdude:

Ah, sorry. Case sensitive. -b kontrolliert die Baudrate zwischen 
Programmer und Host. -B wäre gewesen, was ich meinte.

Mit einer gewissen Eigenintelligenz hättest du mit Hilfe meine Erklärung 
der beabsichtigten Wirkung und Abgleich mit der Dokumentation der 
Parameter von AVRdude wohl auch alleine dahinter kommen können...

Naja, *BSD-User sind wohl auch nicht mehr das, was sie mal waren...

[Raba X. (raba_x)]

c-hater schrieb:
> Raba X. schrieb:
>
>> avrdude: serial_baud_lookup(): Using non-standard baud rate: 10avrdude:
>
> Ah, sorry. Case sensitive. -b kontrolliert die Baudrate zwischen
> Programmer und Host. -B wäre gewesen, was ich meinte.

root@home2l:/ #  avrdude -c stk500v2 -p t85 -P /dev/cuau1 -t -vvv -B 250 -i 90

avrdude: Version 6.4
         Copyright (c) Brian Dean, http://www.bdmicro.com/
         Copyright (c) Joerg Wunsch

         System wide configuration file is "/usr/local/etc/avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cuau1
         Using Programmer              : stk500v2
         Setting bit clk period        : 250.0
         Setting isp clock delay        :  90
avrdude: ser_recv(): programmer is not responding
avrdude: stk500v2_ReceiveMessage(): timeout

--snipp--
>
> Naja, *BSD-User sind wohl auch nicht mehr das, was sie mal waren...
Auch die werden älter. (-;

raba_x

[c-hater (Gast)]

Raba X. schrieb:

>          Using Port                    : /dev/cuau1
>          Using Programmer              : stk500v2
>          Setting bit clk period        : 250.0
>          Setting isp clock delay        :  90
> avrdude: ser_recv(): programmer is not responding

Hier ist offensichtlich schon die Kommunikation zwischen Host und 
Programmer nicht möglich, das sagt doch die Ausgabe ganz eindeutig. Da 
kannst du natürlich für die Kommunikation zwischen Programmer und Target 
einstellen, was immer du willst, es wird nicht funktionieren.

Was mir komisch vorkommt: "/dev/cuau1". Serielle USB-Devices unter BSD
erscheinen gewöhlich als /dev/cuaU(X).
                                 ^
Man beachte auch wieder die "caseness"...

[Hmmm (Gast)]

c-hater schrieb:
> Was mir komisch vorkommt: "/dev/cuau1". Serielle USB-Devices unter BSD
> erscheinen gewöhlich als /dev/cuaU(X).

Genau das dürfte sein Fehler sein.

Dass er Timeouts statt "No such file or directory" bekommt, liegt daran, 
dass es durchaus auch /dev/cuau* gibt, die stammen von uart(4). In 
diesem Fall versucht AVRDUDE es also die ganze Zeit vergeblich auf COM2.

[Raba X. (raba_x)]

Hmmm schrieb:
> c-hater schrieb:
>> Was mir komisch vorkommt: "/dev/cuau1". Serielle USB-Devices unter BSD
>> erscheinen gewöhlich als /dev/cuaU(X).

Der Hersteller hat einen Firmware-Bug in der USB-Implementierung.
Deswegen funktionierte /dev/cuaUx überhaupt nicht.
Mit einem Trace von Joerg Wunsch (Author von avrdude) konnte der 
FreeBSD-USB-Spezialist Hans Petter Selasky den Fehler und gleich einen 
Workaround finden.
Thread in freebsd-hardware:
https://www.mail-archive.com/[e-mail]/index.html#05620

Dank allen, die geantwortet haben,
Raba X

[Pille (Gast)]

c-hater schrieb:
> Raba X. schrieb:
>
>> avrdude: serial_baud_lookup(): Using non-standard baud rate: 10avrdude:
>
> Ah, sorry. Case sensitive. -b kontrolliert die Baudrate zwischen
> Programmer und Host. -B wäre gewesen, was ich meinte.
>
> Mit einer gewissen Eigenintelligenz hättest du mit Hilfe meine Erklärung
> der beabsichtigten Wirkung und Abgleich mit der Dokumentation der
> Parameter von AVRdude wohl auch alleine dahinter kommen können...
>
> Naja, *BSD-User sind wohl auch nicht mehr das, was sie mal waren...

Du kannst Dich auf dem kurzen Dienstweg beschweren, Jörg (TM) als einer 
der Autoren von avrdude ist hier angemeldet (als Mod), Du kannst also 
Dein Unvermögen avrdude zu bedienen (nicht nur unter BSD, die case 
sensitivy ist woanders die Selbe) versuchen direkt ihm anzulasten.

AVRDUDE(1)              FreeBSD General Commands Manual 
AVRDUDE(1)

NAME
     avrdude – driver program for ``simple'' Atmel AVR MCU programmer

SYNOPSIS
     avrdude -p partno [-b baudrate] [-B bitclock] [-c programmer-id]
             [-C config-file] [-D] [-e] [-E exitspec[,exitspec]] [-F]
             [-i delay] [-n -logfile] [-n] [-O] [-P port] [-q] [-s] [-t] 
[-u]
             [-U memtype:op:filename:filefmt] [-v] [-x extended_param] 
[-V]

Gruß,
Pille

[Sven K. (svenk)]

Hallo Axel,
vielen Dank für die Benachrichtigung, was die Ursache für das 
Fehlverhalten war. Das erspart möglicherweise anderen Benutzern Zeit, 
die einen ähnlichen Fehler haben.

Gruß Sven