mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik HEX-file mit STK500 nicht flashbar


Autor: SoLaLa (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hallöle,
ich hab den uralten STK500v1 aus dem Jahr 1783 oder so... (1783 war ein 
hervorragendes Jahr...:-)
Im Lauf der Zeit hab ich damit immer mal wieder kleine Minis in 
Assembler mit dem AVRstudio3 und 4 programmiert... immer wieder ist es 
mal vorgekommen, daß sich die Kiste mitten beim Flashvorgang weggehängt 
hat.
meistens reichte es dann den ISP-Takt mal von (meinen normalen)56 auf 
115 oder auf 4 kHz zu verändern und dann lief das Flashen des jeweiligen 
Files wieder anstandslos durch. Auch warens mal Inkompatibiläten der 
verschiedenen Softwarestände (AVRstudio3.xx und 4.xx) und auch 
verschiedene PCs...

ABER: das HEXfile aus dem Anhang (erzeugt mit WinAVR20070122 unter 
AVRstudio4.14-598) läßt sich nicht flashen... egal wie und was ich 
anstelle, es bricht mittendrin ab. Das File ist zwar kompiliert für nen 
Mega64, aber ich habs auch mal mit nem Mega16 probiert... gleiches 
Ergebnis, Abbruch irgendwo mittendrin. Wenn ich den mega64 danach 
auslese, dann sehe ich, daß etwa 1a00 bis 1e00 words geflasht wurden 
(variiert immer etwas) und dann der Abbruch kam.

Mit Ponyprog2000 läßt sich das File einwandfrei (so wie alle anderen 
auch) flashen und das Programm läuft auch korrekt... dauert mir aber 
ehrlich gesagt viiiiiiiel zu lange.
Kennt jemand dieses Verhalten, bzw. weiß jemand wo hier der Fehler 
liegt?

Autor: Rosettenhengst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

lässt sich problemlos am ATSAM7SE512-EK raufspielen. Habe das 
Olimex-USB-JTAG dazu verwendet.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SoLaLa wrote:
> hallöle,
> ich hab den uralten STK500v1 aus dem Jahr 1783

Kann nicht sein.
Den AVR gibts ja erst seit 1997 und das STK500 seit 2000.


Hast Du denn auch im STK500 die Firmware updaten lassen?


Peter

Autor: SoLaLa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo Peter,
STK500 hat version ..0A
das interessante ist ja, wenn ich am C code mal wieder n bissi was 
ändere, dann läuft das anstandslos durch, auch mit 460k ISPfrequenz. 
Allgemein möcht ich sogar behaupten WENN das proggen klappt, dann auch 
mit allen möglichen geschwindigkeiten. manchmal bekomm ich aber hexfiles 
die nicht auf Anhieb flashbar sind (und dann nach umstellen auf 4kHz 
sich doch flashen lassen).
Aber dieses eine ist dermaßen hartnäckig :-) geht einfach nicht... und 
deshalb interessiert mich halt das warum.
ich hatte da irgendwo mal was gelesen mit $FF oder $F0 oder sowas genau 
an eine Pagegrenze. Aber das war nicht auf STK500 bezogen sondern auf 
irgendnen anderen ISPprogger

Autor: SoLaLa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rosettenhengst:
danke für die Info... aber JTAG wär ja auch ganz fies, wenn das nicht 
ginge :-)
für alle anderen die gerad n bischen rumflashen möchten:
bitte mal kurz ausprobieren ob sich das ding auf nem STK500 oder 
kompatibel auf nen mega64 flashen läßt.

Autor: Kai G. (runtimeterror)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie hast du den ATmega64 an das STK getüddelt?

Kann das STK die Kennung und die Fuses korrekt auslesen?

Autor: Kai G. (runtimeterror)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann es leider nicht testen, da ich weder einen ATmega64, noch ein 
passendes Adapter habe.

Autor: SoLaLa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, hier nochmal n paar infos:

Detecting on 'COM1'...
STK500 with V2 firmware found on COM1
Getting revisions.. HW: 0x02, SW Major: 0x02, SW Minor: 0x0a .. OK
Getting isp parameter.. SD=0x02 .. OK  ===>115kHz

Mega16 auf internem Sockel:
Setting mode and device parameters.. OK!
Entering programming mode.. OK!
Reading signature .. 0x1E, 0x94, 0x03 .. OK!
Leaving programming mode.. OK!

Mega64 auf externem Board:
Setting mode and device parameters.. OK!
Entering programming mode.. OK!
Reading signature .. 0x1E, 0x96, 0x02 .. OK!
Leaving programming mode.. OK!

5V, 16MHz Quarz
Fuses:
Entering programming mode.. OK!
Reading fuses address 0 to 2.. 0xBE, 0xDF, 0xFF .. OK!
Leaving programming mode.. OK!

BODEN war auch schon abgeschaltet, JTAG war auch schon mal probehalber 
eingeschaltet (mußte aber wieder aus, weil ich den PORTF brauche)
SUT_CKSEL war auch schon auf 16k+64ms
hier mal wieder geändert:
Entering programming mode.. OK!
Writing fuses address 0 to 2.. 0xFF, 0xDF, 0xFF .. OK!
Reading fuses address 0 to 2.. 0xFF, 0xDF, 0xFF .. OK!

Fuse bits verification.. OK
Leaving programming mode.. OK!

auf "PROGRAM" geklickt (mit auto erase, ist aber egal, 20mal manuelles 
Löschen vorher bringt auch nix):

Getting isp parameter.. SD=0x02 .. OKOK
Reading FLASH input file.. OK
Setting mode and device parameters.. OK!
Entering programming mode.. OK!
Erasing device.. OK!
Programming FLASH ..      FAILED!   ===> hier läuft jetzt der schöne 
blaue Balken... leider nicht bis zum Schluß durch, sondern bleibt 
mittendrin irgendwo stehen

Leaving programming mode.. FAILED!

zackbummweg... LEDleuchtet orange und nur n Power off/on bringt wieder 
leben in die Kiste.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht ist Dein Netzteil zu schwach und die Spannung aufm STK bricht 
ein.
Wichtig ist auch, daß das Netzteil zum STK erdfrei ist.
Die Erdverbindung darf ausschließlich über Pin 5 der RS-232 erfolgen und 
nirgends anders.
Ideal sind alte Wandwarzen (z.B. 12V/300mA).


Peter

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

Bewertung
0 lesenswert
nicht lesenswert
Da du den ATmega64 offenbar ja extern hast, kommen weitere Fragen auf:

. saubere Masseverbindungen
. nicht zu lange ISP-Kabel
. ordentliche Abblockung des ATmega64

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

Bewertung
0 lesenswert
nicht lesenswert
ATmega64 habe ich gerade nicht, nur einen ATmega128 (in einem STK501
montiert):
% avrdude -p m128 -c stk500v2 -P /dev/ttyS0 -U ~/download/AccuControl.hex 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9702
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "/home/jwunsch/download/AccuControl.hex"
avrdude: input file /home/jwunsch/download/AccuControl.hex auto detected as Intel Hex
avrdude: writing flash (7968 bytes):

Writing | ################################################## | 100% 10.94s

avrdude: 7968 bytes of flash written
avrdude: verifying flash memory against /home/jwunsch/download/AccuControl.hex:
avrdude: load data flash data from input file /home/jwunsch/download/AccuControl.hex:
avrdude: input file /home/jwunsch/download/AccuControl.hex auto detected as Intel Hex
avrdude: input file /home/jwunsch/download/AccuControl.hex contains 7968 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 10.09s

avrdude: verifying ...
avrdude: 7968 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Wenn du mir erzählst, was ich damit machen soll, kann ich noch einen
Funktionstest vornehmen. ;-)  Der ATmega128 sollte zum ATmega64
binärkompatibel sein.

Autor: SoLaLa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke mal für die vielen Tips und Danke Jörg, daß Du das mal eben hast 
durchlaufen lassen.
Ich hab gestern das ganze mal genauer untersucht:
es ist KEIN analoges Problem (Netzteil, Erdung, Entkopplung usw...)
die Versorgungsspannung (auf dem externen Board genauso wie die vom 
STK500) zeigt mir n kleinen 50mV ripple im 100ns bereich, sonst nix.

Ich denke, bin mir mittlerweile ziemlich sicher, daß es ein Problem der 
STK500 Software ist (Probleme der seriellen Schnittstelle mit XP hab ich 
mal durch Test an nem Win98 Rechner ausgeschlossen, der das gleiche 
Verhalten zeigt)

Nachdem ich (danke an dieses Forum) das Logging aktivieren konnte, 
zeigte sich, daß o.g. HEXfile beim flashen immer exakt an der selben 
Stelle hängenbleibt:
Receiving packet 06/27/2008 02:09:24.171
(10000ms) < 1B 51 
(expected 3 more bytes but timed out)
Sequence number 81, message size n/a, checksum n/a
No data in packet
Returned status: Client: Total timeout exceeded (PC side gave up)
Wenn ich dann im Source beispielsweise innerhalb einer Stringkonstante 
nur einen einzigen Buchstaben ändere, dann läuft das flashen anstandslos 
durch. Ändere ich den Buchstaben wieder auf den vorherigen Inhalt, dann 
bleibts flashen wieder reproduzierbar an exakt obiger Stelle hängen.

Autor: SoLaLa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallöle an alle interessierten :-)

ich hab noch n bissi Info und glaube, daß das Problem tatsächlich die 
STK500 Software ist. Ich hab das o.g. Hexfile ---mal wieder--- mit dem 
ponyprog in den mega64 geschaufelt. Dann das mega64board wieder an den 
STK500 gehängt und mit AVRstudio connected.
Ich hab jetzt KEINEN ERASE veranlaßt, sondern schlichtweg nur auf 
"program" geklickt... wie gewohnt bleibt der Flashvorgang mit 
Fehlermeldung kurz vorm Ende stehen und bricht ab.
Danach hab ich den Verify gemacht und eben festgestellt, daß das File 
immer noch vollständig im chip vorhanden war. (wurde ja auch nur 
"drüberkopiert").
Für mich bedeutet das jetzt, daß NICHT das flashen des chips selbst, 
sondern die Kommunikation zwischen STK500 und PC bzw. die Verarbeitung 
der übertragenen Sequenzen im STK500 selbst den Abbruch verursacht.

irgendwelche Ideen?

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

Bewertung
0 lesenswert
nicht lesenswert
SoLaLa wrote:

> ich hab noch n bissi Info und glaube, daß das Problem tatsächlich die
> STK500 Software ist.

Oder in deinen seriellen Treibern.

Gegenbeweis:
% avrdude -p m64 -c stk500v2 -P /dev/cuad0 -Fv -U /tmp/AccuControl.hex

avrdude: Version 5.6cvs, compiled on Jun 13 2008 at 23:21:15
         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/joerg/.avrduderc"

         Using Port                    : /dev/cuad0
         Using Programmer              : stk500v2
         AVR Part                      : ATMEGA64
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom         4    20    64    0 no       2048    8      0  9000  9000 0xff 0xff
           flash         33     6   128    0 yes     65536  256    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          4    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500V2
         Description     : Atmel STK500 Version 2.x firmware
         Programmer Model: STK500
         Hardware Version: 2
         Firmware Version Master : 2.10
         Topcard         : STK501
         Vtarget         : 3.1 V
         SCK period      : 10.9 us
         Varef           : 3.0 V
         Oscillator      : 3.686 MHz

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9702
avrdude: Expected signature for ATMEGA64 is 1E 96 02
avrdude: safemode: lfuse reads as E3
avrdude: safemode: hfuse reads as 11
avrdude: safemode: efuse reads as FF
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "/tmp/AccuControl.hex"
avrdude: input file /tmp/AccuControl.hex auto detected as Intel Hex
avrdude: writing flash (7968 bytes):

Writing | ################################################## | 100% 11.01s

avrdude: 7968 bytes of flash written
avrdude: verifying flash memory against /tmp/AccuControl.hex:
avrdude: load data flash data from input file /tmp/AccuControl.hex:
avrdude: input file /tmp/AccuControl.hex auto detected as Intel Hex
avrdude: input file /tmp/AccuControl.hex contains 7968 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 10.18s

avrdude: verifying ...
avrdude: 7968 bytes of flash verified

avrdude: safemode: lfuse reads as E3
avrdude: safemode: hfuse reads as 11
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Ich habe ihm exta noch einen ATmega64 gefaket (und dann mit -F zum
Weitermachen gezwungen, da ja ein ATmega128 drin ist), damit er
intern exakt so arbeitet wie bei einem ATmega64.  Du kannst in den
Ausschriften auch sehen, dass meine Firmware mit 2.10 exakt deiner
(AVR Studio: 0x02 0x0a) entspricht.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab Dein Hex auch flashen können, aber nur in nen ATMega168, da ich 
keinen größeren habe.

Mein STK500 hat HW: 02, SW: 02,0a

SoLaLa wrote:
> irgendwelche Ideen?

Wenn Du nen Bootloader in den Chip brennst, kannst Du das Hex dann per 
Bootloader flashen.


Peter

Autor: SoLaLa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi ihr lieben mitfühlenden :-)

ich hab soeben den 4. (den vierten) PC getestet mit gleichem Ergebnis... 
Abbruch
das waren jetzt: Asus A7V@1GHz mit win98SE, altes Gericom 1st 
Supersonic@1GHz mit WinXP HomeSP2 (das hat noch ne serielle), AsRock 
K7VT4A@2,6GHz winXP HomeSP2 und dieser ist jetzt n Asus P5LD2@3,46GHz...
sniffsniff...

achja: zwischenzeitlich hatte ich dann auch mal den Weg über AVRdude 
gemacht (unter WinXP)... es lief ein wenig besser, ließ sich manchmal 
sofort, manchmal nachm 3. Anlauf flashen, manchmal aber auch wieder 
garnicht... Um mal wieder ins Jahr 1783 zurückzufallen:
" Das ist Teufelswerk!"

hmmmm... ich werd mir gelegentlich mal was zum Loggen der seriellen 
zusammenstöpseln

Autor: SoLaLa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ahja... das mit dem Bootloader war ja auch ne nennenswerte Idee, muß ich 
mir mal zu Gemüte führen aber gleich ne Frage vorweg:
Wenn der Bootloader dann da drauf ist, wird ab dann immer noch über das 
STK500 mit serieller Schnittstelle das Hauptprogramm übertragen, also 
das STK500-Protokoll benutzt? Wenn ja, dann wäre es n ausgiebigen Test 
wert.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SoLaLa wrote:

> Wenn der Bootloader dann da drauf ist, wird ab dann immer noch über das
> STK500 mit serieller Schnittstelle das Hauptprogramm übertragen, also
> das STK500-Protokoll benutzt? Wenn ja, dann wäre es n ausgiebigen Test
> wert.

Das Übertragen erfolgt dann über RS232 SPARE.

Mein Bootloader benutzt nicht das STK500-Protokoll, da es benötigte 
Funktionen nicht unterstützt (Autobauding, Eindrahtmodus, 
Verbindungsaufbau durch den AVR innerhalb 0,3s nach Poweron-Reset).


Peter


P.S.:
Ein RS232-Sniffer:
http://www.serial-port-monitor.com/free-serial-por...

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

Bewertung
0 lesenswert
nicht lesenswert
SoLaLa wrote:

> achja: zwischenzeitlich hatte ich dann auch mal den Weg über AVRdude
> gemacht (unter WinXP)... es lief ein wenig besser, ließ sich manchmal
> sofort, manchmal nachm 3. Anlauf flashen, manchmal aber auch wieder
> garnicht...

Was passierte, wenn es sich nicht flashen ließ?  Auch wieder compare
errors?

Ist schon irgendwie seltsam, dass alle anderen deine Hexfiles benutzen
können.

Autor: SoLaLa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwischenbericht:
-ISPheader für den 90S8535 auf den SK500 gelötet
-Reset und MCUreset verbogen,
-90S1200 mit dauerLOW stillgelegt
-STK500_90S8535.hex mit Ponyprog geflasht und verifiziert
-auch der EEprom inhalt ist vorher sauber leer und wird dann nach dem 
ersten Start mit den Hard-und Software-Versionsnummern beschrieben (und 
noch n paar andere Sachen, denke mal Takt-/Oszillatorsettings, Vcc/Vtg 
und sowas)
-Verhalten danach beim Programmieren des obigen hexfiles--->keine 
Änderung


@Joerg: Compare- bzw. Verifyerrors hab ich ja nicht, entweder bleibt der 
Flashvorgang stehen, dann wird bis dahin alles sauber übertragen und 
weil der PC keine Antwort mehr vom STK bekommt gibt die Software nach 10 
sec mit nem timeout auf (AVRdude zeigt die timeouts auch an, während 
AVRstudio einfach nur wartet und dann das übliche Fehlerpopup 
erscheint).
Ich hatte ja oben schonmal beschrieben, daß ich den Mega64 mit Ponyprog 
fertig programmiert hatte und dann mit STK500 OHNE VORHERIGES LÖSCHEN 
dasselbe File nochmal "drüberprogrammiert" hab. Die interne 
Programmierlogik des mega64 kann dann immer nur mit ner Erfolgsmeldung 
antworten, die bits des Flashs werden an den entsprechenden Stellen ja 
nur von 1 auf 0 reduziert, da sie aber vorher schon richtig waren gibt 
es danach keine Verifyerrors.
Für den anderen Fall, daß das Flashen ganz durchläuft hatte ich noch nie 
irgendeinen Verifyerror, weder bei diesem noch bei irgendnem anderen 
chip.

Ich kümmer mich mal ums Loggen der seriellen Kommunikation

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

Bewertung
0 lesenswert
nicht lesenswert
Hast du Zugriff auf irgendein unixoides Betriebssystem (Linux, MacOS X,
FreeBSD, PC-BSD, was auch immer)?  Dann würde ich mir das dort nochmal
ansehen.

Ich kann dir nur wiederholen, dass ich nicht die geringsten Probleme
mit deinem Hexfile habe.

Autor: SoLaLa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
einen mit fedora core8 hab ich auch noch...
aber ich hab keine Ahnung was ich für AVRentwicklung auf Linux alles 
brauche...

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

Bewertung
0 lesenswert
nicht lesenswert
SoLaLa wrote:

> aber ich hab keine Ahnung was ich für AVRentwicklung auf Linux alles
> brauche...

Um ein Hexfile zu flashen, brauchst du nur ein avrdude.

Autor: SoLaLa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Uuuuups..." sprach der Fehler, "da bin ich wieder!" :-)

hallöle an alle,
da ich mal wieder n bissi Zeit hatte und auch wieder n bissi bauen mußte 
(Motordrehzahl/Lüfterdrehzahl/Geschwindigkeit/Temperatur/Spannungs- und 
Lüftertakterfassung mit serieller Ausgabe auf n Laptop) kams wie es 
kommen mußte:
das STK500 verweigert recht häufig wie oben beschrieben seinen Dienst... 
grmmmpffff

daher hab ich mir mal auf die Schnelle den USBprogV3 nachgebaut und 
siehe da: alles läßt sich immer anstandslos flashen (aus AVRstudio 
heraus). Hab auch mehrfach die Gegenprobe mit dem STK500 gemacht.
Es muß also wirklich nen Fehler auf diesem alten Board sein, bzw. ein 
bug in der Software im Zusammenspiel mit dem alten V1-Board.

Ich erkläre das Thema hier deshalb mal für erledigt zumal ich mit dem 
USBprog auch sehr gut leben kann... Danke mal an den/die Entwickler des 
USBprog

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.