STM32 CUBE IDE Debuggen ohne Source Code?

Ich will ja lediglich wissen was im RAM drinsteht, wäre auch kein 
Problem den Chip dazu anzuhalten, nur will eben die CUBE IDE immer erst 
was Kompilieren und Flashen bevor Debuggen möglich ist. Es müsste doch 
gehen den RAM auszulesen, im Zweifelsfall wenn man den Chip anhält?

Debug Configurations -> Startup -> Load Image and Symbols

Da kannst Du einstellen was er machen soll.
Dann ausführen (F8), Register und Speicher sind lesbar.

Notfalls musst Du eine andere Startadresse einstellen.

Sieh dir einfach die Parameter in "Debug Configurations" an.

Warum auch immer es geht nicht, wenn ich eine neue Konfiguration 
erstelle ist die Schaltfläche Debug ausgegraut. Anscheinend hat ST da 
eine Sperre eingebaut die verhindert dass einer den RAM eines 
Controllers analysiert, von dessen Firmware er den Source Code nicht 
hat. Werde wohl nicht um ein Gerät von Segger rum kommen, ist zwar 
gerade total doof, weil ich im Moment pleite bis zum geht nicht mehr 
bin, aber anscheinend geht das nicht mit dem STlink.

Die SWD Pins sind offen, aber die CUBE IDE lässt sich einfach nicht 
davon überzeugen dass sie debuggen soll ohne vorher Quellcode zu haben. 
Keine Ahnung warum die das so doof programmiert haben, kann mir nur 
vorstellen dass sie nicht wollten dass darüber einer fremde Firmware 
analysiert.

Also gut, letzter Hinweis:

Nimm irgend ein Blinky Projekt als Grundlage.
Spielt keine Rolle, da es bei richtiger Einstellung nicht geflasht wird.

Bastler schrieb:
> kann mir nur
> vorstellen dass sie nicht wollten dass darüber einer fremde Firmware
> analysiert.

Sind Verschwörungstheorien ansteckend?
Die Debugfunktion in Eclipse möchte ein .elf oder ähnliches file laden, 
wenn das nicht da ist, dann ist der Button grau. Das ist in Eclipse 
einfach intransparent und die Internas sind schwer nachzuvollziehen. 
Deshalb bin ich zu VSCode gewechselt.
Die Funktionalität basiert auf dem gdb, den kann man auch aus der 
Kommandozeile starten und sich an das laufende Target hängen. Wenn man 
Adressen kennt, dann lassen die sich auch auslesen. Mit der .elf Datei 
ist das natürlich bequemer weil man dann mit Symbolen arbeiten kann.

Bastler schrieb:
> kann mir nur vorstellen dass sie nicht wollten dass darüber einer
> fremde Firmware analysiert.

Bei dem Wissen das Du hier zeigst, dürften sich Deine Vorstellungen kaum 
mit der Realität decken.
Außerdem ist es unhöflich Vorsatz zu unterstellen, wenn Dummheit als 
Erklärung ausreicht.

Schau Dir die Grundlagen an und lern erstmal mit den Werkzeugen 
umzugehen bevor Du hier wirre und haltlose Vermutungen äußerst.
Dann wird das alles viel Einfacher.

War nur eine Vermutung von meiner Seite, hätte ja sein können.

Bastler schrieb:
> Die SWD Pins sind offen, aber die CUBE IDE lässt sich einfach nicht
> davon überzeugen dass sie debuggen soll ohne vorher Quellcode zu haben.

Wenn du normal mit der CubeIDE Debuggst, dann kannst du dir alle 
Register und Variablen oder andere Expressions angucken. Die Werte sind 
sogar so benannt wie du sie in einem #define oder enum benannt hast. Wie 
soll sie das machen oder Break Points setzen, wenn sich keinen Code und 
keine Memory Map hat?