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:
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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:
@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.
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:
# 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.
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.
Thread beobachten
Seitenaufteilung abschalten