Hallo, einfache Frage zunächst. Hat das jemand am Laufen? Es gibt bereits den Thread "STM32F4-Discovery und Crossworks". Dort scheint mir aber Crossworks unter Linux zu laufen. Ich bekomme einfach den Debugger nicht mit dem On-Board STlink/V2 zum kooperieren. Heinz
Bei mir läuft das STM32F4_discovery Board unter Linux+Crossworks, allerdings Mint 11 (Ubuntu-Derivat). Versuche es doch einmal als root-user. Meistens ist das ein Rechteproblem wegen der USB-Ports. Dazu gibt es übrigens eine Hilfe auf der Rowley-Webseite. Welchen Fehler bekommst du angezeigt (unten in der Statuszeile, weiß auf rotem Grund ...) ?
Entschuldigt die etwas späte Antwort. Die Ausschrift von Cossworks ist "can not set USB configuration" Und in /var/log/messages Jun 12 15:04:33 uschi kernel: [96794.146050] usb 2-10: usbfs: interface 0 claimed by usbfs while ' crossstudio' sets config #1 Ich denke es liegt generell am Kernel und dem usbfs. Es gibt auch hier im Form ähnliche Meldungen, zwar nicht mit dem STLink Debugger, sondern mit Kameras, Scannern, etc aber ich bin trotzdem zu keiner Lösung gekommen. Heinz
Es gibt auf der Crossworks-Supportsite eine Beschreibung, wie man den/die USB-Debugadapter zum Laufen bringt. Bei mir waren das ST-Link und CrossConnect-Lite. Im Prinzip geht es darum, USB-Geräte mit einer spezifischen Product-/Vendor-ID einem bestimmten user zuzuordnen. Allerdings kannst du die Anleitung (http://www.rowley.co.uk/arm/CrossConnect_Install/ReadMe.htm) nicht 1:1 umsetzen, weil SuSe nicht das angegebene Verzeichnis /etc/udev/rules.d verwendet ... Wo das unter SuSe ist, mußt du wohl selbst herausfinden ... Sie machen übrigens noch so Einiges anders - das war der Hauptgrund für mich, auf Mint umzusteigen. Anmerkung: ST-Link V1 (STM32VL_Discovery) wird unter Linux von Crossworks nicht unterstützt, alle späteren "Discoveries" setzen auf V2 auf und funktionieren. Wenn es trotzdem nicht funktioniert - versuche es einmal mit einem Firmwareupdate für den ST-Link Teil. Neuere Firmware-Versionen gibt es auf der ST-Webseite, ebenso wie das "ST-Link Utility", mit dem du den Flash löschen/beschreiben und diverse Controller-Register anschauen kannst. Mit demselben Tool kannst du auch die ST-Link Firmware (im Discovery-Board) updaten). Viel Glück.
Hallo frame, frame schrieb: > ... > Allerdings kannst du die Anleitung > (http://www.rowley.co.uk/arm/CrossConnect_Install/ReadMe.htm) nicht 1:1 > umsetzen, weil SuSe nicht das angegebene Verzeichnis /etc/udev/rules.d > verwendet ... > Wo das unter SuSe ist, mußt du wohl selbst herausfinden ... Ganz so einfach ist die Sache leider nicht. Ich habe auch schon etliche Runden mit dem Rowley-Support hinter mir. Er ist fleißig, ohne Frage, aber helfen konnte er bisher nicht, Die udev/rules.d gibtes in der Suse auch, an der gleichen Stelle. > Wenn es trotzdem nicht funktioniert - versuche es einmal mit einem > Firmwareupdate für den ST-Link Teil. Das wäre noch einen Versuch Wert. > Neuere Firmware-Versionen gibt es > auf der ST-Webseite, ebenso wie das "ST-Link Utility", mit dem du den > Flash löschen/beschreiben und diverse Controller-Register anschauen > kannst. Mit demselben Tool kannst du auch die ST-Link Firmware (im > Discovery-Board) updaten). > > Viel Glück. Danke für die Hinweise Kennt jemand das STlink/V2 Protokoll? Wir sind Heute ein Stück weiter gekommen. Durch Dazwischenschalten von eigenen Funktionen kommen wir nun soweit, das auf dem USB Daten ausgetauscht werden. Nach dem 4. Frage/Antwort Spiel hört der Debugger aber auf. Wenn man nur wüsste, was er dort abfragt? Und als Antwort haben will. Heinz
Wußte ich natürlich nicht, daß du schon ein paar Support-Runden gedreht hast. Auf alle Fälle habe ich einen ST-Link (separat, NICHT Bestandteil eine Discovery-Boards), und den habe ich definitiv updaten müssen, bevor er funktioniert hat. Dann habe ich damit auch einen LPC1769 debuggen können (lpclink wird von CrossWorks auch nicht unterstützt, weil ClosedSource). Sonst kann ich dir wohl nicht weiterhelfen. Mir fällt noch ein, daß ich auch mit der LPCXpresso-IDE unter SuSe große Probleme hatte. Der Debugadapter (LPCLink) wurde nur erkannt, wenn ich den nslookup-Dämon von SuSe ageschossen habe (gibt dazu auch einen Forum-Thread unter http://knowledgebase.nxp.com/forumdisplay.php?f=4). Gruesse Frank
Nochmals Danke, jetzt ist erst mal für 2 Tage Ruhe. Vielleicht fällt mir ja noch etwas ein, oder es kommen noch Hinweise. Inzwischen versuche ich auch den Kontakt zum Entwickler der Stlink.so (?) zu bekommen. Warum so etwas nicht Open Source ist verstehe ich auch nicht. Heinz
> Inzwischen versuche ich auch den Kontakt zum Entwickler der Stlink.so
(?) zu bekommen.
Darauf setzt (z.B.) die Summon-Arm-Toolchain auf (bzw. benutzt die
stlink Software als Treiber). Konnte ich bei mir auch ohne Probleme
kompilieren ...
Bis jetzt habe ich es (leider...) noch nicht bereut, von SuSe auf Mint
umgestiegen zu sein.
Falls du wie ich ein Dualboot-System hast, kannst du CrossWorks auch
unter Windows verwenden. Und da es der gleiche Rechner ist, brauchte ich
nicht einmal einen neuen Lizenzschlüssel. Die Version unter Windows habe
ich speziell für die VL_Discovery, die nicht unter CW/Linux laufen.
Noch ein kleiner Hinweis am Rande.
Wenn du Anwendungen von anderen toolchains nach CrossWorks portierst,
unbedingt den Defaultwert für den Stack hochsetzen. CW setzt nur
lächerliche 128 Byte an, ich habe da schon stundenlang gesucht...
Mal eine bloede Frage, wenn ihr Linux verwendet, warum uebersetzt ihr euch nicht einen einen passenden gcc, st-link und passt dann noch Eclipse an? Habe ich hier problemlos unter anderem mit dem 32F4 laufen. Olaf
> Mal eine bloede Frage, wenn ihr Linux verwendet, warum uebersetzt ihr > euch nicht einen einen passenden gcc, st-link und passt dann noch > Eclipse an? Weil Eclipse erstens ein dampfender Haufen Sch**** ist, und ich zweitens noch einige andere Controllerboards ---ohne--- STLink habe, für die ich SW entwickle. Der erste Punkt ist sicher Geschmackssache, da kann jeder machen was er will. Wer Eclipse mag und dessen Konzept gut findet - meinetwegen. Aber eine eigene Toolchain für jedes Controllerderivat ist mir etwas zu viel des Guten. Übrigens ist der CrossWorks (ARM) Compiler auch ein gcc-Derivat.
> Weil Eclipse erstens ein dampfender Haufen Sch**** ist, Ich haette nicht gedacht das es hier noch MaennerInnen gibt. Natuerlich kannst du auch aus Emacs raus uebersetzen. Traut man sich ja heute kaum noch zu sagen wo die ganzen Milchbubis und Maeuseschubser unterwegs sind. :-] Eclipse wird im uebrigen grenzwertig akzetabel wenn man den Emacs-Mode installiert, die DArstellung auf schwarzen Hintergrund schaltet, Rechtschreibueberpfuefung, Autovervollstaendigung und 30% der Codeueberpruefung abschaltet. Aber ich gebe zu das es schon ein System das dafuer gedacht ist Leuten das programmieren zu erlauben dies es besser nicht tun sollten. > Aber eine eigene Toolchain für jedes Controllerderivat ist mir > etwas zu viel des Guten. Wie willst du sonst unterschiedliche Controllerfamlien unterstuetzen? Die Mitglieder einer Famlie gehen dann natuerlich mit demselben Compiler und entsprechenden Uebergabeparameter. Ich hab mir gerade jeweils einen Compiler fuer SH2, M16C und ARM generiert und verwende die alle in Eclipse. > Übrigens ist der CrossWorks (ARM) Compiler auch ein gcc-Derivat. Ach so, das wusste ich nicht. Olaf
Hallo, alle die versucht haben mir zu helfen - vielen Dank. Gestern hatte ich mal wieder CrossWorks geöffnet und auch versucht mit dem F4 zu arbeiten. Seltsamerweise klappte es dieses mal. Ich kann mit dem Debugger Programme Flashen und auch Debuggen :-) Eigentlich habe ich seit den letzten vergeblichen versuchen nur ab und an das System aktualisiert. Irgendwas mystisches muss passiert sein. Wichtig, ich kann nun mit CrossWorks arbeiten (bis zum nächsten zypper up ?) Heinz
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.