Hallo ihr! Ich arbeite mit einem Mikrocontroller vom Typ STM32F407 (F4DiscoveryBoard) und VisualStudio mit VisualGDB. Für mein Projekt möchte ich nun einen weiteren µC gleichen Typs einsetzen, beide sollen dann miteinander kommunizieren. Welche Möglichkeiten gibt es hier um beide Controller gleichzeitig zu debuggen? Zusätzlich bin ich in Besitz eines externen ST Links V2. Danke schonmal! Grüße Reggie
> Welche Möglichkeiten gibt es hier um beide Controller > gleichzeitig zu debuggen? Du koenntest dir zwei J-Links kaufen. Damit hab ich das schon gemacht. Kostet aber. :-) Olaf
Ich kenn das Vischual-Zeug nicht, aber was spricht dagegen 2 Debugger gleichzeitig laufen zu lassen?
Olaf schrieb: > Du koenntest dir zwei J-Links kaufen. Damit hab ich das schon gemacht. > Kostet aber. :-) Mit J-Link kann man doch daisy chainen? Braucht man da dann doch zwei? rmu schrieb: > Ich kenn das Vischual-Zeug nicht, aber was spricht dagegen 2 Debugger > gleichzeitig laufen zu lassen? War mein erster Gedanke, ist es damit möglich, dass sich die Controller dann wie ein System verhalten? Sprich, beispielsweise an einem Breakpoint beide Controller pausieren?
Die Discovery und Nucleo Boards kommen mit dem STLink, mit dem man Debuggen kann. Jeder STLink hat eine eindeutige Nummer, mit der man den Stlink gezielt ansprechen kann.
Reginald L. schrieb: > War mein erster Gedanke, ist es damit möglich, dass sich die Controller > dann wie ein System verhalten? Sprich, beispielsweise an einem > Breakpoint beide Controller pausieren? Nö, eher nicht. Aber das willst Du ja wohl auch gar nicht, oder? Reginald L. schrieb: > beide sollen > dann miteinander kommunizieren. Wenn der eine sendet, wirde der andere wohl empfangen. Dann werden auch kaum dieselben Breakpoints sinnvoll sein.
Markus F. schrieb: > Wenn der eine sendet, wirde der andere wohl empfangen. Dann werden auch > kaum dieselben Breakpoints sinnvoll sein. Bei der Kommunikation untereinander eher weniger, da hast du recht, merke ich gerade. Ich melde mich nochmal falls das unter anderen Umständen doch praktisch wird. Danke euch erstmal!
Habe mich heute auf die zwei µC gestürzt, es lassen sich nun beide gleichzeitig anschließen und je nach Projektauswahl ansprechen (mithilfe ST-Link ID). Allerdings gelingt es mir nicht, beide gleichzeitig zu debuggen, ich bekommen eine Fehlermeldung von VisualGDB. Hat jemand hiermit schon Erfahrungen gesammelt? Email an den Support ist zwar raus, aber vielleicht hat ja hier noch jemand einen Tipp. Danke schonmal!
:
Bearbeitet durch User
Hi, kann Deine Aufgabe nachvollziehen - muss gerade gleichzeitig viermal F4 debuggen. :) Ich weiß nicht, ob Du mehrere Instanzen von Deiner Entwicklungsumgebung aufmachen kannst? Wenn ja - dann ein Projekt in der einen IDE, das andere in der anderen. (Atollic kann das) Wenn nein, dann kannst Du eine virtuelle Maschine für jede IDE-Instanz aufmachen. (die Lösung für CooCox 1.7) Aber eine IDE, die sagen wir mal, zwei JTAG-Devices mit zwei Quelltexten im selben Workspace gleichzeitig debuggen kann, das wäre mir was neues. Gruß, marcus
Ja, VisualStudio macht richtig spaß :) Mehrere Entwicklungsumgebungen, kein Problem. Allerdings ist es angenehmer mit einem Knopfdruck beide Projekte gleichzeitig zu debuggen. Vor allem habe ich auch noch ein Projekt das auf Windows debuggt wird und mit dem Controller kommuniziert. Da kommt es mir schon gelegen, zwei Instanzen von VS zu öffnen. Aber die Controllercodes möchte ich schon gleichzeitig unter einer IDE-Instanz debuggen, da die beiden ein System bilden. Mit VS ist sowas auch möglich. Nur der VisualGDB Debugger macht hier Probleme. Das Builden, Verlinken und überspielen der beiden Projekte geht auch ohne Probleme gleichzeitig vonstatten. Nur wenn GDB mit dem Debuggen anfängt, bringt er mir einen Fehler. Es scheint, als ob der Debugger nur auf ein Target zugreift, anders als OpenOCD. Ich könnte die Bildschirmausgabe hier posten, vllt kann ja Jemand damit etwas anfangen? Marcus H. schrieb: > Aber eine IDE, die sagen wir mal, zwei JTAG-Devices mit zwei Quelltexten > im selben Workspace gleichzeitig debuggen kann, das wäre mir was neues. Ich benutze zwar nur ST-Links, aber daran habe ich noch gar nicht gedacht, dass so etwas nicht üblich wäre.
:
Bearbeitet durch User
Reginald L. schrieb: > Marcus H. schrieb: >> Aber eine IDE, die sagen wir mal, zwei JTAG-Devices mit zwei Quelltexten >> im selben Workspace gleichzeitig debuggen kann, das wäre mir was neues. > > Ich benutze zwar nur ST-Links, aber daran habe ich noch gar nicht > gedacht, dass so etwas nicht üblich wäre. Auch der ST-Link kann JTAG. Und wenn Du Chips mit 1MB Flash beackern darfst, willst Du ein flottes Interface. SWD kommt bei mir nur bei kleinen Chips zum Einsatz, bzw. wenn der Pincount ein Thema ist. Aber Du hast recht, ich hab mich nur net getraut "2x Segger J-Link" zu schreiben. ;)
:
Bearbeitet durch User
Marcus H. schrieb: > Auch der ST-Link kann JTAG. Man lernt nie aus ;) Ich geh mal an die Arbeit ran, das langsame Debuggen nervt nämlich. Vielleicht mag das der VisualGDB eher. Herzlichen Dank!
Ah, ok. Für den nichtkommerziellen Einsatz gibt es den J-Link EDU für 50€. Das ist der schwarze J-Link BASE (298€ netto) in weiß. https://www.segger.com/j-link-edu.html http://shop.segger.com/J_Link_p/8.08.00.htm Schreib mal ein 100kB Binary in ein JTAG-fähiges Target mit z.B. STM32F4 und vergleich die Geschwindigkeit mit den ST-Link oder OpenOCD. Bei 16kB Binary noch kein Drama, jenseits 64kB wird's interessant. Ich habe einen Kunden mit F4, wo der FW-Entwickler ST-Links einsetzen muss. Da höre ich am Telefon immer "er lädt noch", während es bei mir schon läuft. Und für Ferneinsätze gibt's dann den hier: ;) https://www.segger.com/jlink-pro.html
Heureka! So, habs hinbekommen, kann gleichzeitig mit zwei verschiedenen ST-Links debuggen, in einem VisualStudio, in einer Projektmappe. Falls jemand das gleiche Problem hat, melden (VisualGDB) :)
Congrats! Magst Du ein bisserl erzählen, was im Nachhinein die Probleme waren und wie Deine Lösung funktioniert? Grüße, marcus
Marcus H. schrieb: > Congrats! > Magst Du ein bisserl erzählen, was im Nachhinein die Probleme waren und > wie Deine Lösung funktioniert? > Grüße, > marcus Gerne doch, eigentlich absolut simpel, wenn man sich ein klein wenig mit der Funktionsweise eines Toolchains auskennt (was ich nicht wirklich tue): VisualGDB klinkt sich nach dem Kompilieren und Linken in OpenOCD ein. Dies geschieht über den TCP-Port 3333, soviel habe ich mithilfe des VisualGDB Logs schon rausgefunden gehabt. Wenn man nun ein Projekt debuggt, also über Port 3333 Kommunikation stattfindet, blockiert Windows logischerweise diesen Port. Ich sags ja: Total simpel. Genauso wie die Lösung: neuer Port muss her. Da fing die Problematik für mich an, da ich mich mit Toolchains noch nie wirklich beschäftigt habe. Eigentlich ein grober Fehler, wenn man einen Controller programmiert aber ich bin erst letzten Sommer in die Elektronik eingestiegen und wollte natürlich auch Erfolge sehen und fühlen. Mithilfe des Supports von VisualGDB (SysProgs) habe ich es dann doch hinbekommen: Für jede Projektkonfiguration (Release, Debug, ...) erstellt VisualGDB eine Config (*.vgdbsettings), in welcher schon ein vorbereiteter Schlüssel für die die Startparameter von OpenOCD angelegt ist:
1 | <Key>com.sysprogs.arm.openocd.initargs</Key> |
Hier muss man folgendes als Value übergeben:
1 | <Value>-c "gdb_port 3334"</Value> // Unglücklich gewählter Port, funktioniert aber |
Da es nur eine Config für OpenOCD gibt, muss eine Variable in Abhängigkeit des Projekts übergeben werden. Also trägt man noch den folgenden Schlüssel in die VisualGDB-Config ein:
1 | <KeyValue> |
2 | <Key>com.sysprogs.openocd.port</Key> // Die Variable für OpenOCD |
3 | <Value>3334</Value> // Port |
4 | </KeyValue> |
Jetzt noch in die OpenOCD-Config die Variable eintragen. Die Config befindet sich unter: "C:\Users\Werkstatt\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sy sprogs.arm.openocd\edp.xml" Und der Schlüssel der eingetragen werden muss:
1 | <GDBStartupCommands> |
2 | <string>target remote :$$com.sysprogs.openocd.port$$</string> |
3 | </GDBStartupCommands> |
Damit hat man nun VisualGDB und OpenOCD ermöglicht beliebig viele Prozesse zu starten. Was jetzt noch fehlt, ist die Verlinkung von OpenOCD und den ST-Links. Anscheinend schnappt sich OpenOCD immer den erstbesten Debugger. Nun kann man OpenOCD aber sagen, welchen Debugger er wählen soll. Dies geschieht über eine Target-Config die sich unter "C:\Users\Werkstatt\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sy sprogs.arm.openocd\share\openocd\scripts\interface\stlink-v2.cfg" befindet. Dort sieht das dann mit eingegebener Serial etwa so aus:
1 | #
|
2 | # STMicroelectronics ST-LINK/V2 in-circuit debugger/programmer
|
3 | #
|
4 | |
5 | interface hla |
6 | hla_layout stlink |
7 | hla_device_desc "ST-LINK/V2" |
8 | hla_vid_pid 0x0483 0x3748 |
9 | hla_serial "DÿfJ‡=A&(d ‡" // Hier die Serial |
10 | |
11 | # Optionally specify the serial number of ST-LINK/V2 usb device. ST-LINK/V2
|
12 | # devices seem to have serial numbers with unreadable characters. ST-LINK/V2
|
13 | # firmware version >= V2.J21.S4 recommended to avoid issues with adapter serial
|
14 | # number reset issues.
|
15 | # eg.
|
16 | #hla_serial "\xaa\xbc\x6e\x06\x50\x75\xff\x55\x17\x42\x19\x3f"
|
Unter folgendem Link ist beschrieben, wie man die Serial eines ST-Links V2 ausliest: http://stackoverflow.com/questions/29121050/openocd-debugging-multiple-devices-at-once Viel Spaß beim "multiple device debugging" :)
Mir ist gerade aufgefallen, dass ich in dieser Konfiguration Probleme mit den Breakpoints habe. Wenn ich mehr in Erfahrung bringe melde ich mich wieder.
Mit zwei Instanzen von VisualStudio treten keinerlei Probleme auf. Ich muss auch sagen, dass für mich das Debuggen mit zwei eigenen VisualStudio Instanzen ergonomischer ist.
Reginald L. schrieb: > Welche Möglichkeiten gibt es hier um beide Controller gleichzeitig zu > debuggen? Zusätzlich bin ich in Besitz eines externen ST Links V2. Die günstigste ist die UART Schnittstelle ;-)) vom beiden µC den UART anzapfen und per HyperTerminal die meldugen ausgeben lassen.
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.