Forum: Mikrocontroller und Digitale Elektronik OPENOCD mit JLINK am STM32f103


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Thorsten E. (bluescreen)


Bewertung
0 lesenswert
nicht lesenswert
Da mein ST-Link Klon von einem Tag auf den anderen Plötzlich seinen 
Dienst quittiert hat, versuche ich nun mit einem antiken J-Link Klon und 
OOCD meinen STM32f103 zu flashen. Klappt aber nicht.

OOCD erkennt den J-Link und auch den Prozessor. Wenn ich aber "reset 
halt" eingebe läuft das ganze auf einen Timeout. Gebe ich es getrennt 
ein, also erst "reset" und dann halt, scheint es zu funktionieren.

Dann funktioniert auch der "flash" Befehl scheinbar. Allerdings läuft 
das vorher mit dem st-Link geflashte Bin-File auf Breakpoint, den es 
aber gar nicht gibt (siehe bp Befehl).

Auch ein Resume hilft nicht, das Programm startet nicht mehr. Und exakt 
dasselbe bin File lief vorher mit dem ST-LinkV2 an.

Hier die Startsequenz vom OOCD:
1
C:\Users\Thorsten>openocd.exe -f interface/jlink.cfg -f target/stm32f1x.cfg
2
Open On-Chip Debugger 0.9.0 (2015-05-19-12:06)
3
Licensed under GNU GPL v2
4
For bug reports, read
5
        http://openocd.org/doc/doxygen/bugs.html
6
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
7
adapter speed: 1000 kHz
8
adapter_nsrst_delay: 100
9
jtag_ntrst_delay: 100
10
none separate
11
cortex_m reset_config sysresetreq
12
Info : J-Link ARM-OB STM32 compiled Dec  3 2009 11:40:54
13
Info : J-Link caps 0x88ea5833
14
Info : J-Link hw version 70000
15
Info : J-Link hw type J-Link
16
Info : J-Link max mem block 67102240
17
Info : J-Link configuration
18
Info : USB-Address: 0x0
19
Info : Kickstart power on JTAG-pin 19: 0x0
20
Info : Vref = 3.300 TCK = 1 TDI = 0 TDO = 1 TMS = 1 SRST = 1 TRST = 1
21
Info : J-Link JTAG Interface ready
22
Info : clock speed 1000 kHz
23
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
24
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
25
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

Dann die Telnet Session mit OOCD:
1
Open On-Chip Debugger
2
> reset halt
3
JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
4
JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
5
timed out while waiting for target halted
6
TARGET: stm32f1x.cpu - Not halted
7
in procedure 'reset'
8
in procedure 'ocd_bouncer'
9
10
11
Halt timed out, wake up GDB.
12
> reset
13
JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
14
JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
15
> halt
16
target state: halted
17
target halted due to debug-request, current mode: Thread
18
xPSR: 0x01000000 pc: 0x08004cea msp: 0x2000ffcc
19
> flash write_image erase C:/Entwickl/WinARM/Projects/Blink_STM32F1/default/Blink_STM32F1.bin 0x08000000
20
auto erase enabled
21
wrote 36864 bytes from file C:/Entwickl/WinARM/Projects/Blink_STM32F1/default/Blink_STM32F1.bin in 2.413138s (14.918 KiB/s)
22
> reset run
23
JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
24
JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
25
target state: halted
26
target halted due to breakpoint, current mode: Thread
27
xPSR: 0x61000000 pc: 0x2000003a msp: 0x2000ffcc
28
> bp
29
>

von W.S. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Thorsten E. schrieb:
> Info : J-Link ARM-OB STM32 compiled Dec  3 2009 11:40:54

Hmm... das Datum sieht mir etwas verwirrend aus, um das mal so zu sagen. 
Aber einen Versuch ist es wert: versuche mal mit JFlash-Lite und diesem 
Onboard-JL deinen Controller zu programmieren, vielleicht geht es. 
Ansonsten gibt es von Segger auch ein Programm, um aus einem ST-Link-OB 
einen J-Link-OB zu machen UND: notfalls daraus wieder einen ST-Link 
zurück zu machen.

Ansonsten guck einfach mal beim freundlichen Chinesen nach deren 
ST-Links. Sind billig, so daß du dir ne Handvoll davon leisten kannst.

Wenn du's eiliger hast, dann guck hier mal nach einem von mir geposteten 
kleinen Projekt mit nem STM32F103, das zwar auf der Schaltung des 
ST-Links beruht, aber alle Pins herausgeführt hat und sich auch per 
Bootlader brennen läßt. Wer will, kann sich die Originalfirmware des 
ST-LinkV2 im Netz suchen und dort draufbrennen, dann hat man eben ein 
selbstgepfriemeltes ST-Link2. Mein Anliegen war das nicht, ich hatte 
bloß ein paar Chips herumliegen und wollte mir ne Minimalst-LP machen, 
die möglichst UN-exotisch ist und sich notfalls auch auf ein Steckbrettl 
plazieren läßt.

Tja, auf meine Weise mit Bootlader bin ich bislang eigentlich recht gut 
gefahren, jedenfalls hab ich damit all den Stress nicht, den man mit 
JTAG und SWD so hat. Wie ist dir denn dein ST-Link kaputt gegangen?

W.S.

von Thorsten E. (bluescreen)


Bewertung
0 lesenswert
nicht lesenswert
Mein STLinkV2 war so ein billiges China-Teil. Bis vorgestern 
funktionierte er noch. Dann den Rechner heruntergefahren und am nächsten 
Tag wieder hochgefahren und Windows erkennt ihn nicht mehr. "Unbekanntes 
Gerät" sagt es und dass es wegen "Fehlern deaktiviert" wurde. Man sieht 
in der Systemsteuerung nichtmal die PIDs.

Dann an einen Linuxrechner gestöpselt und im Log sieht man 
verbindungsfehler, auch keine PIDs. Scheint also fast tot zu sein, aber 
nicht ganz, sonst würde ja nichts passieren beim Einstecken.

Achja, er blinkt im 10 Sekundentakt.

Das J-Link wäre ja eigentlich sogar besser, da es auch Nicht-ST-ARMs 
bearbeiten kann. Und anscheinend geht es ja auch, bis auf den RESET HALT 
Befehl.

Ein Firmwareupdate habe ich mich nicht getraut, da ich gelesen habe, 
dass neuere Firmwaren des J-Links erkennen, dass sie auf einem Klon 
laufen und diesen dann bricken.

Und ganz ohne JTAG finde ich doof wegen Debugging. Und (zumindest auf 
den LPCs) ist es gähnend langsam.

von W.S. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Thorsten E. schrieb:
> Achja, er blinkt im 10 Sekundentakt.

Dann guck dir lieber mal dein USB-Kabel UND die Buchse an. Ich hatte das 
schon mehrfach, daß manche Buchsen ausleiern oder keinen guten Kontakt 
geben.

Ansonsten finde ich das Brennen per Bootlader nicht wirklich gähnend 
langsam. Klar: Es ist so um Faktor >10 langsamer als SWD, aber was 
solls? Dafür ist man nicht auf China-Clones usw. angewiesen. Bei dem 
erwähnten STM32F103-Miniprojekt braucht es zum Brennen so um die 5 
Sekunden und dann nochmal dasselbe für's Verify. Ist keine Rakete, jaja, 
aber dafür hab ich im Brennprogramm auch gleich ein Terminalfenster und 
kann damit mit der soeben gebrannten Firmware kommunizieren. Sowas ist 
für mich wesentlich wichtiger, als mal eben 9.9 Sekunden einzusparen. 
Den Debugger habe ich schon seit Ewigkeiten nicht mehr benötigt. Deshalb 
ist mir die Debugmöglichkeit über SWD herzlich wurscht.

W.S.

von Thorsten E. (bluescreen)


Bewertung
0 lesenswert
nicht lesenswert
Ok, bei solchen Zeiten würde es gehen. Ich hatte mit einem LPC2148 
angefangen und der hat für das Flashen via Bootloader ca. 25 Sekunden 
gebraucht. Das war mir zu langsam. Wenn es 5 Sekunden dauert geht es ja.

Nur wie findet man einen Fehler der anscheinend schon VOR dem Ausführen 
des eigenen Programms eintritt. Im Moment läuft das Ding direkt auf 
einen Hardfault.
Allerdings scheint das wirklich am JTAG Interface zu liegen. Der 
Reset-Befehl (auch reset init oder reset halt) bewirkt anscheinend 
nichts. Der PC steht nach dem Reset Befehlt irgendwo im RAM. Wenn man 
dann resume macht gehts natürlich schief.

Macht man ein soft_reset_halt setzt er brav den PC auf den Reset 
Handler. Mit Resume läuft dann artig das eigene Program los.
Irgendwie scheint also der J-Link Clone Murks zu sein. Vielleicht doch 
mal trauen, ein Firmwareupdate zu machen.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten E. schrieb:
> Info : auto-selecting first available session transport "jtag". To
> override use 'transport select <transport>'.

Versuche mal:
1
C:\Users\Thorsten>openocd.exe -f interface/jlink.cfg -c "transport select swd" -f target/stm32f1x.cfg

SWD braucht weniger Pins und funktioniert manchmal besser.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten E. schrieb:
> none separate
> cortex_m reset_config sysresetreq

Hast Du den Reset Pin angeschlossen? In der Config ist er jedenfalls als 
"nicht angeschlossen" markiert (none separate). Siehe "help 
reset_config" im OpenOCD.

von Thorsten E. (bluescreen)


Bewertung
0 lesenswert
nicht lesenswert
Das ändert nicht. Reset halt läuft immer noch auf einen Timeout und der 
PC steht nach einem Flashen im RAM und lässt sich nur durch 
soft_reset_halt korrekt setzen.

von Thorsten E. (bluescreen)


Bewertung
0 lesenswert
nicht lesenswert
Das mit dem reset_config scheint es zu sein! Habe mal reset_config srtst 
eingeben und nun scheint es zu funktionieren.

Wie stelle ich das nun als Default ein?

: Bearbeitet durch User
von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Bau Dir eine eigene board.cfg zusammen.

von Thorsten E. (bluescreen)


Bewertung
0 lesenswert
nicht lesenswert
Da versteh ich erstmal nur Bahnhof. Anscheinend setzt die stm32f1x.cfg 
die Einstellung zurück mit diesen Zeilen:

if {![using_hla]} {
    # if srst is not fitted use SYSRESETREQ to
    # perform a soft reset
    cortex_m reset_config sysresetreq
}

Weil ja using_hla anscheinend nicht gesetzt ist. Aber wenn er gesagt 
bekommt er soll softreset verwenden, warum tut er das denn nicht. Der 
Befehl soft_reset_halt tut ja auch was er soll. Und was ist using_hla 
überhaupt.

Irgendwie schlimm, man muss erst die Scriptprachen von mindestens drei 
Tools lernen bis man endlich irgendwas BENUTZEN darf.

von W.S. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Thorsten E. schrieb:
> Irgendwie schlimm, man muss erst die Scriptprachen von mindestens drei
> Tools lernen bis man endlich irgendwas BENUTZEN darf.

Tja, verstehst du jetzt meine Position etwas besser?

W.S.

von Thorsten E. (bluescreen)


Bewertung
0 lesenswert
nicht lesenswert
Ich verstehe immer mehr, dass dieses ganze STM Zeugs nichts für mich 
ist.

Jetzt kriege ich die SPI Schnittstelle nicht zuverlässig in Gang. 
Manchmal gehts manchmal nicht. Mal ist nur der Datenpin aktiv und der 
Takt fehlt, manchmal geht beides. Strobe geht gar nicht. Vor allem, dass 
es bei jedem Reset anders ist kann doch wohl nicht sein. Ist das ein 
Prozessor oder ein Lottozahlengenerator.

Ich versteh die Dinger nicht. Vielleicht doch lieber bei den AVRs 
bleiben.

Alles was früher vom 8085, Z80, 68000 bis zu den AVRs in ein paar 
Minuten in Gang war macht hier nur Probleme.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt auch noch NXP mit den LPCs: 32 Bit Timer, 32 Bit SPI, 32 Bit 
DMA, dezimal einstellbare Vorteiler, bootloader im ROM, gute Doku... :-)

von Thorsten E. (bluescreen)


Bewertung
0 lesenswert
nicht lesenswert
Eigentlich ist ja sogar der LPC2148 die Zielplattform. Nur ist das 
Flashen via Seriell so unerträglich langsam. Aber jetzt habe ich ja 
einen JLink. Vielleicht gehts damit ja besser.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten E. schrieb:
> Eigentlich ist ja sogar der LPC2148 die Zielplattform. Nur ist das
> Flashen via Seriell so unerträglich langsam.

Da muß ich mal reinhaken: Benutzt du FlashMagic? Dort kann man doch die 
Übertragungsgeschwindigkeit in gewissen Grenzen vorgeben.

Es spielt natürlich das innere Procedere des PC-Programms auch noch eine 
Rolle, also ob der Code vom Hexfile zunächst in einem Puffer 
zwischengespeichert wird, so daß man dann unabhängig vom Input-Format 
mit Blöcken passender Länge zum Bootlader hin arbeiten kann, oder ob 
jede Zeile aus dem Hexfile in ihrer aktuellen Länge abgearbeitet wird.

Ich hatte bislang noch nicht das Bedürfnis, mir eine Konkurrenz zu 
FlashMagic selber zu schreiben - bei den STM32 hingegen war mir das 
bitter nötig, denn das, was ST da mit seinem Flash-Loader-Demonstrator 
und Konsorten vorgelegt hat, war mit schlichtweg grauselig und der 
Erfos-Brenner ist zu alt.

Nur deshalb hatte ich mich dazu hinreißen lassen, sowas selber zu 
schreiben. Aber inzwischen finde ich, daß es sich gelohnt hat. Nun, das 
Grundgerüst steht ja, also sollte es keine unüberwindliche Hürde sein, 
eine Variante für die LPC zu machen. Aber davor steht wohl, erstmal die 
Grenzen von FlashMagic auszuloten.

W.S.

von Thorsten E. (bluescreen)


Bewertung
0 lesenswert
nicht lesenswert
Ja, ich benutze Flashmagic am LPC2148 Board. Das Board ist mit einem 12 
MHz Quarz bestückt, damit die USB Schnittstelle des LPC2148 
funktioniert. Damit bekomme ich Flashmagic über UART aber nur maximal 
38.400 Bd. Damit dauert dann das Flashen des 90kB (Hexfilegröße) großen 
mitgelieferten Demoprograms etwa 80 Sekunden.

Tausche ich den Quarz gegen einen 14,768 MHz, kann ich bis zur 
Maximalbaudrate von 230400 Bd hochgehen und brauche dann ca. 15 Sekunden 
für das Demoprogramm, was akzeptabel wäre.

Ich versuche morgen mal über den J-Link Adapter zu flashen, zum 
Geschwindigkeitsvergleich.

Was natürlich cool wäre, einen USB Bootloader zu implementieren. Am 
besten einen der nach aussen kompatibel mit dem Originalen ist. Das 
heißt er meldet sich als Serialport auf den man dann mit Flashmagic 
losgehen kann. Aber sowas habe ich noch nicht gefunden. Und da fehlt mir 
im Moment die Erfahrung, so ewtas zu basteln.

Aber wenn es mit dem J-Link vielleicht auch geht, ist JTAG vielleicht 
doch nicht so übel.
Was mir auch bei den ganzen ARMs noch nicht klar ist und was ich auch 
nicht wirklich im Datenblatt gefunden habe, ist diese SWD 
(Debugging/Flashing über eine Zweidrahtverbindung. Unterstützen dies 
grundsätzlich alle ARMs oder nur die von ST. Wenn alle, müsste man ja 
auch mit so einem Schmalspur STLink andere Hersteller flashen können.

P.S.:
meinen J-Link am STM32F103 habe ich in Gang bekommen, indem ich die 
Zeilen mit der HLA-Bedingungen aus der stm32f1x.cfg entfernt habe. Schon 
nimmt er die Standard Reset Einstellungen und schon gehts.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
SWD können die meisten modernen Cortex-M, ob die SWD/JTAG Linie jetzt 
genau zwischen denen und ARM7TDMI verläuft weiß ich nicht, aber beim 
LPC2148 habe ich nichts von SWD im DB gelesen.
Für die LPC ist der LPCLink2 noch relativ günstig, mit ca. 25€ 
(watterott) und kann auch auch JTAG und SWD und kann per Firmware 
Änderung verschiedene probes emulieren. Die 2148 kann der sicher auch 
flashen, dazu braucht es ja noch die flashloader die NXP für sein 
eigenes Zeug haben sollte.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten E. schrieb:
> Da versteh ich erstmal nur Bahnhof. Anscheinend setzt die stm32f1x.cfg
> die Einstellung zurück mit diesen Zeilen:
>
> if {![using_hla]} {
>     # if srst is not fitted use SYSRESETREQ to
>     # perform a soft reset
>     cortex_m reset_config sysresetreq
> }

Du solltest Dir nur das "board" Verzeichnis mit den Config Files mal 
genauer anschauen.

Ein für Dich passende board.cfg müsste so aussehen:
1
source [find interface/jlink.cfg]
2
3
transport select swd
4
source [find target/stm32f1x.cfg]
5
6
# use hardware reset, connect under reset
7
reset_config srst_only srst_nogate

Aufruf von openocd ist dann nur
1
openocd.exe -f board/myownboard.cfg

von Thorsten E. (bluescreen)


Bewertung
0 lesenswert
nicht lesenswert
@Johannes: Stimmt, der LPCLink2 sieht nicht schlecht aus. Aber bisher 
anscheinend nicht wirklich offen und daher nur mit wenig Software 
nutzbar. Aber für LPC gehts ja anscheinend und bei dem Preis macht man 
nicht soviel verkehrt. Was ich nur schade finde, dass man anscheinend 
für jeden Controller seinen JTAG Adapter braucht. Das gefällt mir am 
OpenOCD. Da scheint man mit einigen Adaptern nahezu alles bedienen zu 
können. Dafür ist es aber wieder teilweise Gefrickel. Kein Vorteil ohne 
Nachteil.

@Jim: Danke für den Tipp. Insbesondere, dass man Einstellungen aus einer 
Konfig Datei in der nächsten auch wieder zurücknehmen kann. Ich würde 
allerdings das Interface eher aus der Boardkonfig rausnehmen. Vielleicht 
nutzt man ja mal den einen und mal den anderen Adapter.

So, und nun zu den Ergebnissen mit meinem LPC2148 in Verbindung mit dem 
JLink Clone.
Erstmal ging gar nichts (warum wundert mich das nicht mehr ?). Mit den 
geheimnisvollen Worten -c "jtag_khz 1000" gings dann aber.
Resultat: Flashen der 90kB großen Hexdatei dauert 13 Sekunden!

Allerdings scheint es noch Probleme beim Reset zu geben. Das große 
Testprogramm läuft an, flackert aber am Anfang etwas auf dem Display 
herum, was es ohne angeschlossenem J-Link nicht tut. Danach funktioniert 
das Display aber.

Mein eigenes Testprogramm, das einen Zähler auf dem 2-zeiligen Display 
anzeigen soll, initialisiert das Display nicht richtig, es wird nur die 
erste Zeile angesteuert.
Ich muss nochmal den Schaltplan studieren. Vielleicht hängt das Display 
irgendwie an den JTAG Pins.

von Thorsten E. (bluescreen)


Bewertung
0 lesenswert
nicht lesenswert
Noch eine Frage zur Board Konfiguration in OpenOCD.
Um performant und ohne lästige Warnungen flashen und debuggen zu können 
muss ich folgende Befehle in der Telnet Session eingeben:

  arm7_9 fast_memory_access enable
  arm7_9 dcc_downloads enable

Wo baue ich die im Boardfile ein? Im Moment sieht mein Boardfile so aus:
1
#
2
# NGX Technology Blueboard  http://www.shop.ngxtechnologies.com
3
#
4
5
source [find target/lpc2148.cfg]
6
7
# some commands needed for proper inititialization
8
set core_freq_khz 12000
9
set adapter_khz 1500
10
adapter_khz 1000
11
#dcc_downloads enable
12
#fast_memory_access enable
13
14
$_TARGETNAME configure -event reset-init {
15
  halt
16
  wait_halt 1000#
17
18
  arm7_9 fast_memory_access enable
19
  arm7_9 dcc_downloads enable
20
}

Der Abschnitt _TARGETNAME funktioniert aber nicht, da _TARGETNAME 
anscheinend nicht gesetzt wird. Abgesehen davon vermute ich, es ist 
nicht nötig das in den reset_init Handler zu tun, weil es anscheinend 
ausreicht dieses einmal zu setzen.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thorsten E. schrieb:
> Was mir auch bei den ganzen ARMs noch nicht klar ist und was ich auch
> nicht wirklich im Datenblatt gefunden habe, ist diese SWD
> (Debugging/Flashing über eine Zweidrahtverbindung. Unterstützen dies
> grundsätzlich alle ARMs oder nur die von ST. Wenn alle, müsste man ja
> auch mit so einem Schmalspur STLink andere Hersteller flashen können.

Ganz kurz:
1. SWD gibt es erst seit der Erfindung der Cortexe. Die etwas älteren 
ARM7TDMI, ARM9xx usw. kennen das nicht.

2. Falls dein J-Link-Clone nicht allzu vergurkt ist, dann benutze zum 
Flashen lieber Segger's JFlash-lite, das geht auch mit den J-Link-Edu's 
- im Gegensatz zum normalen J-Flash.

3. OpenOCD hab ich nie zum stabilen Laufen bringen können, es war immer 
irgendein Gefrickel dabei nötig - und sowas kann ich überhaupt nicht 
leiden.

W.S.

von Thorsten E. (bluescreen)


Bewertung
0 lesenswert
nicht lesenswert
J-Flash (in beiden Versionen) hatte ich schon probiert. Es findet meinen 
J-Link Klon nicht. Im Gegensatz zu OpenOCD.

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]
  • [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.