Atollic TrueSTUDIO Debugging -> SWV funktioniert nicht

[Daniel R. (sparker)]

Hallo,

kennt sich hier jemand mit Atollic aus, ich komme mitsamt der Hilfe beim 
Debugging nicht zurecht. Mein Hautproblem ist, dass der SWV-Viewer 
überhaupt nicht funktioniert.

Ich habe versucht, die Statistical Profiling-Funktion zu nutzen, aber 
das Ding zeigt mir überhaupt nichts an.

Jetzt wollte ich zumindest eine grobe Abschätzung der Laufzeit von ein 
paar DSP-Funktionen haben mit:
#define ITM_Port32(n) (*((volatile unsigned long *)(0xE0000000+4*n)))
.
ITM_Port32(31)=1;
Funktionen();
ITM_Port32(31)=2;

Der SWV-Trace Log - Viewer gibt gar nichts aus.

ST-Link-V2-Clone wird als Debugger verwendet, SWD ist aktiviert.
Einstellungen wurden laut Videos von Atollic und auch verifiziert mit 
dem Atollic Truestudio for Arm User Guide gemacht.
-siehe Bilder!

Hat jemand eine Idee dazu?
(Breakpoints und Registerwerte auslesen klappt übrigens.)

[Daniel R. (sparker)]

Ich glaub ich hab den Fehler:
Der SDO-Pin ist ja für Real-Time Tracing nötig, aber der ist ja gar 
nicht beim STLink-V2 angeschlossen,
- den kann man wohl nicht mit diesem Debugger verwenden, oder?

[Rainer M. (excogitator)]

Beim orginal ST-Link v2 gibt es diesen Pin  (Pin 13 des 20-poligen 
Steckers) - siehe auch Tabelle 4 im User Manual. Keine Ahnung ob so ein 
ST-Link Clone auch einen Trace-Pin hat.

Gruß
Rainer

[Christopher J. (christopher_j23)]

Daniel R. schrieb:
> SDO-Pin

... oder auch SWO-Pin


Rainer M. schrieb:
> Keine Ahnung ob so ein ST-Link Clone auch einen Trace-Pin hat.

Die großen natürlich schon aber die "mini"-Versionen nicht. Genausowenig 
wie eine Resetleitung. Beides kann man mit ein bisschen Bastelei nach 
außen führen.

[Stefan F. (Gast)]

Guck Dir mal die Fotos ab Ende dieses Kapitels an: 
http://stefanfrings.de/stm32/index.html#stlink

Da siehst du, wo wie man die SWO Leitung nachrüsten kann.

[Curby23523 N. (Gast)]

Einfach einen original-programmer verwenden..

[Stefan F. (Gast)]

Bei mir läuft das Atollic Studion 9.0.0 unter Debian 9u3 gar nicht.

Alle Dialogfenster sind zu klein, so daß ich wichtige Buttons nicht 
sehen kann - auch wenn ich den Font auf kaum noch lesbare Größe 
verringere.

Beim Versuch, mein Blinky Programm zu compilieren stürzt es ohne 
hilfreiche Fehlermeldung ab. Auch wenn ich einfach nur einen "clean" 
versuche. Im Console Fenster erscheint gar nichts.

Ich versuche es später nochmal, vielleicht wenn das Programm aus den 
Kinderschuhen raus ist.

[Harry L. (mysth)]

Stefan U. schrieb:
> Ich versuche es später nochmal, vielleicht wenn das Programm aus den
> Kinderschuhen raus ist.

Da ist nix mit "Kinderschuhen".
Das ist Eclipse, und die Effeke, die du beschreibst, deuten eher auf 
Probleme mit deinem installierten GTK hin.

[edit]
Wenn man das Programm in einer Konsole startet, sieht man auch 
Fehlermeldungen.

[Stefan F. (Gast)]

Andere Eclipse versionen laufen bei mir ohne Probleme.

Ich probiere glich mal aus, es im Konsole Fenster zu starten. Und ich 
probiere es mal mit einem frischen lokalen User (wegen Konfig- und 
Temp-Files).

[Bernd S. (wirrer_haarschopf)]

Stefan U. schrieb:
> Bei mir läuft das Atollic Studion 9.0.0 unter Debian 9u3 gar nicht.

Unter Windows 10 läuft es recht gut. Hab bisher noch keine Probleme 
festgestellt. Ich denke aber auch, dass es ein Problem mit deiner 
Linuxinstallation ist. Denn das zurgunde liegende Eclipse wurde von ST 
sicher nicht in dieser Hinsicht verändert.

[Stefan F. (Gast)]

Mit einem neuen Linux User läuft die IDE. Leider konnte ich noch nicht 
herausfinden, welche Konfiguration hier entscheidend ist.

Ich habe folgendes gelöscht:

~/.config/gtk-2.0
~/.config/gtk-3.0
~/-config/dconf/user

Außerdem habe ich Gnome Tweak Tool alles wieder zurückgesetzt (dazu gibt 
es einen Menüpunkt). Das hat aber alles nichts geholfen. In den 
Dialogfenster sie rechts und untern immer noch einige Buttons außerhalb 
des sichtbaren Bereiches. Fenster größer machen nützt nichts.

Starten im Terminalfenster hat auch keine neuen Erkenntnis gebracht. Ich 
erhalte dort exakt die gleichen Warn-Meldungen wie mit dem neuen User 
der kein Darstellungsproblem hat.

Wie gesagt funktionieren zwei andere Ecipse Installationen hingegen ohne 
Probleme.

Falls noch jemand einen Tip hat, was ich prüfen/löschen könnte, würde 
ich mich freuen.

[Harry L. (mysth)]

Ist ein Schuss ins Blaue, aber damit konnte ich bei mir 
Darstellungsprobleme in Eclipse beheben:

In die Datei ~/.profile folgende Zeile anhängen:

export SWT_GTK3=0

[Stefan F. (Gast)]

Harry du bist ein Schatz!
Das hat geholfen. Gibt es dazu auch eine Erklärung?

[Harry L. (mysth)]

Stefan U. schrieb:
> Harry du bist ein Schatz!
> Das hat geholfen. Gibt es dazu auch eine Erklärung?

Da musst du mal googeln!
Ich hab mich da auch nicht tiefer mit bescäftigt.
Java ist einfach nicht meine Welt. ;)

[Bernd S. (wirrer_haarschopf)]

Und wo es nun bei allen läuft und auch das Problem des TO geklärt ist, 
wie findet ihr das neue, kostenlose TrueStudio im Vergleich zu SW4STM? 
Wo liegen die Unterschiede?

Im Großen und Ganzen scheint es ja sehr ähnlich zu sein.

[Stefan F. (Gast)]

Ich habe das AtollicSTUDIO gestern den ganzen Abend bis spät in die 
Nacht durchprobiert. Zuerst unter Windows (wegen der oben genannten 
inzwischen gelösten Probleme), dann unter Linux.

Mir sind auf die schnelle keine wesentlichen Unterschiede aufgefallen, 
nur folgende Kleinigkeiten:

Das Atollic TrueSTUDIO verwendet bei neuen Projekten immer die 
StdPeriphLib, obwohl ST auf der Webseite schreibt, dass man das nicht 
mehr machen soll.

In den Compiler/Linker Optionen sind etwas mehr Einstellmöglichkeiten 
(Kommandozeilenparameter) grafisch aufbereitet, als bei der System 
Workbench.

In den Debugger Einstellungen kann man SWO (ITM trace Messages) auf 
einen IP Socket leiten. Die System Workbench hat dazu kein Pendant (kann 
man aber manuell in eine cfg Datei eintragen).

Ich vermisse den Dialog "Target/Program Chip...". Scheinbar muss man den 
Debugger anwerfen, um das Programm ins Target zu übertragen (oder ein 
externes Tool benutzen).

Leider ist das TrueSTUDIO ebenfalls wie die System Workbench eine wilde 
Mischung aus 32bit und 64bit binaries, was vor allem bei Linux den 
Installationsaufwand für zusätzliche Libraries erhöht. Man sollte 
meinen, dass 32bit Anwendungen von der Bildfläche verschwunden sein 
sollten.

Im Support Forum von der System Workbench hat ein ST Mitarbeiter 
geschrieben, das die drei primären Entwicklungsumgebungen nach wie vor 
KEIL, IAR und System Workbench seien und dass dies nach aktuellem 
Planungsstand auch so bleiben soll. Atollic haben sie angeblich 
aufgekauft, um Know-How ins Haus zu holen.

Da beide IDE's funktional fast identisch sind wäre es für mich hingegen 
logisch, wenn sie die System Workbench zu gunsten des Atollic TrueSTUDIO 
raus werfen würden. Aber das ist reine Spekulation.

Eine gute Nachricht habe ich allerdings: Das Atollic TrueSTUDIO kann 
Projekte von der System Workbench übernehmen und konvertieren. Nur 
anders herum geht es nicht. Deswegen bleibe ich vorläufig bei der System 
Workbench.

[Christopher J. (christopher_j23)]

Wenn ich das richtig sehe, dann hat Atollic ein paar Debugging-Features, 
welche die SW nicht hat. Eines wäre die automagische Erkennung ob ein 
Fault aufgetreten ist und wenn ja, was für einer.

Stefan U. schrieb:
> Da beide IDE's funktional fast identisch sind wäre es für mich hingegen
> logisch, wenn sie die System Workbench zu gunsten des Atollic TrueSTUDIO
> raus werfen würden. Aber das ist reine Spekulation.

Ich gehe sogar fest davon aus, dass sie langfristig die System Workbench 
nicht weiter supporten. Man darf nicht vergessen, dass die SW nicht von 
ST, sondern von AC6 stammt. AC6 ist ein Consultingunternehmen, welches 
zwar einen Fokus auf STM32 hat (im Bereich Cortex-M) aber eben nicht mit 
ST verheiratet ist. Auf deren Website schreiben sie auch eindeutig, dass 
sie ihre Dienstleistungen eben z.B. auch für LPC und Kinetis von NXP 
anbieten.

[Bernd S. (wirrer_haarschopf)]

Danke für den ausführlichen Bericht, Stefan!

Stefan U. schrieb:
> Im Support Forum von der System Workbench hat ein ST Mitarbeiter
> geschrieben, das die drei primären Entwicklungsumgebungen nach wie vor
> KEIL, IAR und System Workbench seien und dass dies nach aktuellem
> Planungsstand auch so bleiben soll. Atollic haben sie angeblich
> aufgekauft, um Know-How ins Haus zu holen.

Was ich von solchen Aussagen zu halten habe, sehe ich jeden Tag in 
meiner Firma (großes, über die ganze Welt verteiltes Softwareunternehmen 
in der Finanzbranche, bei dem ein großer Teil des Produktmanagement 
sogar wie bei ST in Frankreich sitzt), nämlich nichts. Den ST 
Mitarbeiter, der die Aufgabe hat in Supportforen zu schreiben, hat sein 
Produktmanagement wohl nur noch nicht darüber unterrichtet, dass es 
seine Meinung geändert hat. Passiert bei uns ständig. Macht das Leben 
spannend... ;)

Stefan U. schrieb:
> Ich vermisse den Dialog "Target/Program Chip...". Scheinbar muss man den
> Debugger anwerfen, um das Programm ins Target zu übertragen (oder ein
> externes Tool benutzen).

Den hab ich auch vermisst. Ich denke, da möchten sie, dass wir den neuen 
STM32CubeProgrammer benutzen. Der kann dann die .elf Dateien direkt über 
den STLINK brennen. Das alte STM32 STLink Utility konnte das nicht, nur 
.hex usw. Da musste man erst mit objcopy umwandeln.

Stefan U. schrieb:
> In den Debugger Einstellungen kann man SWO (ITM trace Messages) auf
> einen IP Socket leiten. Die System Workbench hat dazu kein Pendant (kann
> man aber manuell in eine cfg Datei eintragen).

Das will ich mir auch noch anschauen. Hab irgendwo gelesen, dass das 
jetzt einfach in einem Fenster in der IDE angezeigt werden kann. 
(Scheint aber doch nicht so einfach zu sein.) -> EDIT: Im user_guide.pdf 
ab Seite 287 ist es eigentlich recht gut beschrieben, wie es geht. Werde 
es spätestens am Wochenende mal ausprobieren.

[Bernd S. (wirrer_haarschopf)]

Bernd S. schrieb:
> Stefan U. schrieb:
>> In den Debugger Einstellungen kann man SWO (ITM trace Messages) auf
>> einen IP Socket leiten. Die System Workbench hat dazu kein Pendant (kann
>> man aber manuell in eine cfg Datei eintragen).
>
> Das will ich mir auch noch anschauen.

Hab es gerade mal ausprobiert. Es ist wirklich beeindruckend, was da 
möglich ist und es geht weit über die "lightweight" Ausgabe von 
Debugmeldungen hinaus.

Man hat nicht nur einen seriellen Debugport, sonder sogar 32 "ITM 
channels/ports" und alle können einfach in der IDE angezeigt werden. 
Außerdem kann man Schreib- und Lesezugriffe auf bis zu 4 Speicherstellen 
gleichzeitig protokollieren, es kann die Häufigkeit von 
Funktionsaufrufen protokolliert werden usw.

Diese beiden Beiträge im Atollic Blog geben eine gute Einführung (kann 
man auch als White Paper in PDF-Form herunterladen):
http://blog.atollic.com/cortex-m-debugging-printf-redirection-to-a-debugger-console-using-swv/itm-part-1
http://blog.atollic.com/cortex-m-debugging-printf-redirection-to-a-debugger-console-using-swv/itm-part-2