2 STM32 debuggen

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!

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.

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. ;)

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

Marcus H. schrieb:
> Da höre ich am Telefon immer "er lädt noch"

Musste grad lachen :>

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" :)

Danke, reggie!

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.