Professioneller Debugger für STM32

Segger J-Link mit OZone wenn es nur um das Debuggen geht.

Lauterbach mit Trace

> Mir ist klar, dass ein Lauterbach sowas kann, aber möchte zeitgleich
> möglichst "günstig" bleiben.

Witzbold

https://www.segger.com/products/debug-probes/j-link/models/j-link-plus/
https://www.segger.com/products/debug-probes/j-link/models/j-link-edu-mini/
https://www.segger.com/purchase/pricing/jlink-related/

https://www.segger.com/products/development-tools/ozone-j-link-debugger/
https://www.segger.com/products/debug-probes/j-link/tools/j-scope/
https://www.segger.com/products/development-tools/embedded-studio/

drm schrieb:
> ST ist bolle stolz drauf das die kostenlose CubeIDE (wie Keil/IAR) alles
> mit ST-Link oder J-Link auf die Kette kriegt. Einfach mal im YT Kanal
> von ST stöbern ...

STM32CubeIDE ist, wie so viele andere Eclipse-basierten IDEs, der letzte 
Rotz in Sachen Debugging. Am schlimmsten finde ich dabei, dass der 
Debugger es nicht schafft, mehrere Symbole mit demselben Wert (z.B. 
0x00000000) sauber auseinanderzuhalten. Und selbst solche vermeintlich 
einfachen Dinge wie das Darstellen der Elemente einer Struktur ab einer 
beliebigen Basisadresse sind unmöglich oder extrem umständlich.

Deswegen verwende ich von der CubeIDE nur den GCC und die Binutils. Als 
Editor den UE Studio, als Build-System ein durch STM32CubeMX generiertes 
und anschließend händisch deutlich aufgebohrtes Makefile, und als 
Debugger einen Lauterbach TRACE32.

wut schrieb:
> Während der Core läuft kann man doch nicht parallel Register etc.
> auslesen?

Der ST-Link V2 kann unter EmBitz zur Laufzeit zwar nicht Register, aber 
immerhin Variablen (und damit auch Peripherie-Register) life sichtbar 
machen, ohne den Kern anzuhalten. Grenzen hat das leider bei den 
Float-Registern.

wut schrieb:
> Wenn Segger ein solches Feature anbietet, wenden die da bestimmt Tricks
> an, d.h. die Laufzeit deines Programms wird in jedem Fall beeinflusst.

Natürlich wird die Laufzeit beeinflusst. Schon allein deshalb, weil 
alles über den Bus geschaufelt werden muss.

Olaf schrieb:
> Das kann man einfach nicht Klickibunti machen.

Doch, Lauterbach bietet den allergrößten Teil der Funktionalität auch 
per Klickibunti an, aber es lässt sich natürlich alles auch in 
PRACTICE-Skripte packen. Diese Sprache hat zwar nicht die Eleganz 
mancher modernen Skriptsprache, ist aber für den Zweck sehr gut 
geeignet.

wut schrieb:
> Wenn Segger ein solches Feature anbietet, wenden die da bestimmt Tricks
> an, d.h. die Laufzeit deines Programms wird in jedem Fall beeinflusst.

Je nach Ausstattung des Chips verfügt die Debugunit über einen 
Mem-Access-Port. Typischerweise hängt der einfach als weiterer Master an 
der Busmatrix und kann auf jeden Speicher wann er will zugreifen. Dann 
sieht man alles was im Speicher abgeht in (fast) Echtzeit. Man kann dann 
auch Variablen ändern und schauen was die Software daraufhin macht.

Für Register existiert sowas glaube ich nicht, macht imho auch nicht 
viel Sinn. (Da brauchts dann eher ETM bzw. ITM Debugeinheit und eine 
passende Software dazu)

egal schrieb:
> Also meines erachtens sollte sich das Debug-Interface auch einfach wie
> ein weiterer Bus-Master verhalten.

Zum Cortex-M4 schreibt ST

1

• The AHB-AP is an AHB master into the Bus Matrix.

2

 Consequently, it can access all the data buses (Dcode Bus,

3

 System Bus, internal and external PPB bus) but the ICode bus.

4

 • Bitband transactions are supported.

nachdem auch der Private Peripheral Bus (PPB) dabei ist, kommt man 
praktisch an alles ran, mit Ausnahme der Core Register. Bei einem Fault 
werden die aber gerettet, also bleibt nicht viel. Sind R0 bis R12 in 
einem optimierten Programm überhaupt interessant? Coprocessor Register 
sind leider noch ganz was anderes.

> Ich habe beruflich früher mal mit den TriCores gearbeitet und da ging
> das auch, dass man auf alle Peripherie-Register zugreifen konnte.

Eben alles, was memory-mapped ist.

Bauform B. schrieb:
> Bei einem Fault
> werden die aber gerettet

Wenn man sich einen Faulthandler schreibt, der das macht, dann 
sicherlich.
Ansonsten werden bei einem Fault die gleichen Register vom NVIC stacked, 
wie bei nem IRQ.

Bauform B. schrieb:
> Sind R0 bis R12 in
> einem optimierten Programm überhaupt interessant?

Klar, wenn man den Sourcecode und ein Assemblerlisting hat. IMO ist der 
Assemblercode optimierter Programme sogar besser lesbar, weil weniger 
sinnloses Hin-und-Her-Kopieren drin ist. Wenn man also genau weiß wo es 
geknallt hat, kann man mit den Registerwerten durchaus was anfangen.

Mw E. schrieb:
> Wenn man sich einen Faulthandler schreibt, der das macht, dann
> sicherlich.

Wenn man einen Breakpoint in den Faulthandler setzt oder den Debugger so 
konfiguriert, beim Auftreten eines Faults zu unterbrechen, kann man die 
Prozessor-Register auch "normal" auslesen. Die Anwendung wird wohl kaum 
nach Auftreten eines Fault weiter laufen müssen...

W.S. schrieb:
> aber man darf das Ganze nicht
> gar zu sehr übertreiben.

Wie kann man effiziente Fehlersuche "übertreiben", und wer verbietet es?

Die J-Links kann ich jedenfalls auch empfehlen, die ST-Links... weniger.

egal schrieb:
>> Für Register existiert sowas glaube ich nicht, macht imho auch nicht
>> viel Sinn. (Da brauchts dann eher ETM bzw. ITM Debugeinheit und eine
>> passende Software dazu)
>
> Also meines erachtens sollte sich das Debug-Interface auch einfach wie
> ein weiterer Bus-Master verhalten.
>
> Ich habe beruflich früher mal mit den TriCores gearbeitet und da ging
> das auch, dass man auf alle Peripherie-Register zugreifen konnte.

Ja, hab mich schlecht ausgedrückt. Ich meinte die CPU Register. (Ich 
verwende den Begriff Register nur selten in Verbindung mit 
Peripherieeinheiten)

Johannes S. schrieb:
> CPU Register konnte afaik schon das ältere ST-Utility anzeigen.

Das kann so ziemlich jeder Debugger bei so ziemlich jeder CPU die ich 
kenne solange die CPU steht. Mir ging es darum, dass es meiner Meinung 
nach wenig Sinn macht die CPU Register in Echtzeit während die CPU läuft 
zu "sehen". Man kann das sowie nicht zuordnen.

Niklas G. schrieb:
>> Sind R0 bis R12 in
>> einem optimierten Programm überhaupt interessant?
>
> Klar, wenn man den Sourcecode und ein Assemblerlisting hat. IMO ist der
> Assemblercode optimierter Programme sogar besser lesbar, weil weniger
> sinnloses Hin-und-Her-Kopieren drin ist. Wenn man also genau weiß wo es
> geknallt hat, kann man mit den Registerwerten durchaus was anfangen.

Genauso ist es. Wir hatten mal einen Fall dass ein Embedded OS bei 
Taskunterbrechung (Premption durch höherpriore Task nach Interrupt) die 
Condition Flags im CPSR nicht wieder hergestellt hat. Das war sehr 
spaßig, wenn ein Teil von einem "if" ausgeführt wird und der andere Teil 
nicht. Sowas findet man nur wenn man in die Register schaut und den 
Assembler dazu versteht. Zum Glück ist ARM Assembler gut lesbar.

Niklas G. schrieb:
> Wenn man einen Breakpoint in den Faulthandler setzt oder den Debugger so
> konfiguriert, beim Auftreten eines Faults zu unterbrechen, kann man die
> Prozessor-Register auch "normal" auslesen. Die Anwendung wird wohl kaum
> nach Auftreten eines Fault weiter laufen müssen...

Er schrieb ja explizit von sichern, daher meine Aussage.
Die Anzeige des Faults ist je nach IDE unterschiedlich in der Qualität.
Der Faultanzeiger der IAR für Cortex-M zB ist recht schlecht und zeigt 
auch oft mal nichts an.

Daher hatte ich mir da mal Handler selber geschrieben.
Die geben das wahlweise per UART aus oder packen es in ein struct.
Der BKPT kommt dann wenn das struct gefüllt ist.
Dieser Handler klamüsert auch schon die Faultbits auseinander.
Damit sieht man gleich, dass es zb ein laden eines struct vom 
Nullpointer war.

Andreas M. schrieb:
> Genauso ist es. Wir hatten mal einen Fall dass ein Embedded OS bei
> Taskunterbrechung (Premption durch höherpriore Task nach Interrupt) die
> Condition Flags im CPSR nicht wieder hergestellt hat.

Das ist aber schon ein übles Problem des RTOS, das kann man schon nicht 
mehr als "Bug" bezeichnen - zumal die Cortex-M das xPSR ja automatisch 
wiederherstellen, wenn man denn den richtigen Stack hat.

Olaf schrieb:
> Lustig finde ich es immer wieder wenn hier so getan wird als wenn das
> nur Profis bei krassen Problemen brauchen. Aber gerade Anfaenger sollten
> unbedingt mal ihrem Programm mit dem Debugger auf die Fuesse schauen.

Absolut, und auch die Bedienung des Debuggers lernen, das gehört m.M.n 
zu den Grundfertigkeiten des Programmierens. Wer im Berufsleben keine 
Debugger benutzt weil er "das nicht kann" (so schwierig ist es nun auch 
nicht) bzw. "noch nie gemacht hat", macht etwas falsch. Programmieren 
sollte man ohnehin erst am PC lernen, und dort ist der Debugger in den 
meisten IDEs einfach direkt und problemlos nutzbar; mit dieser Erfahrung 
will man den Debugger im Embedded-Bereich dann auch nicht mehr missen.