STM32 Cube IDE Inline Assembler

Stefanus F. schrieb:
> Nur 3 ist echt ein bisschen wenig. In meinem C Programmen waren
> mindestens 5 möglich, soweit ich mich erinnere.

Ja möglich sind meine ich bis zu 6 Stück, deshalb finde ich ja den 
Fehler so komisch...und der tritt nur auf, wenn ich versuche "asm 
volatile" zu debuggen...

Dr. Sommer schrieb:
> Leopold N. schrieb:
>> An der Anzahl der Breakpoints kann es nicht liegen (siehe Anhang)
>
> Wie viele Hardware-Breakpoints unterstützt dein Prozessor denn?
>
> Versucht die IDE vielleicht mehrere temporäre interne Breakpoints auf
> Einmal zu setzen, um durch den Assembler zu steppen? Vielleicht klappt
> es im Single-Instruction Modus.

Wie kommt man in den Single Instruction?

Stefanus F. schrieb:
> Der STM32L072 unterstützt nur 4 Unterbrechungspunkte und der erste
> wird
> von der IDE am Programm-Anfang gesetzt. Welchen Mikrocontroller
> verwendest du denn? Wer das weiß, kann einen Blick in Reference Manual
> werfen.

Ich benutze den STM32F103C8T6 und meine gelesen zu haben, dass es 6 
waren (nagelt mich net drauf fest :) )
Ich habe jetzt den Single Instruction Mode eingestellt, aber das ändert 
leider nichts.

Dr. Sommer schrieb:
> Was passiert wenn du das testweise auf der GDB-Konsole machst,
> ohne IDE?
> Was, wenn du dabei schon 1,2...6 Breakpoints gesetzt hast?

Keine Ahnung, benutze GDB nicht "pur".
Warum auch immer, jetzt geht es plötzlich.
Ich werde noch ein bisschen rumspielen und wenn ich den Grund weiß, 
schreib ichs euch.

Dr. Sommer schrieb:
> PS: Du könntest auch versuchen einen normalen Breakpoint auf die
> Zeile
> nach dem "asm" zu setzen und dann "Continue" zu nutzen. Ist eh mehr oder
> weniger das Gleiche.
>
> PPS: "__asm__" ist kompatibler als nur "asm" (funktioniert auch mit
> -std=cXY)

Ah ok, dann werde ich in Zukunft wohl besser _asm_ benutzen.

Das mit dem Breakpoint hatte ich auch schon versucht, hat nix gebracht.

Nur weil das bisher noch nicht gefragt wurde: Setzt du den Breakpoint eh 
zum Anfang vom asm Block und nicht auf den String der Instruktion?

Vincent H. schrieb:
> Nur weil das bisher noch nicht gefragt wurde: Setzt du den
> Breakpoint eh
> zum Anfang vom asm Block und nicht auf den String der Instruktion?

Auf die Zeile, wo asm steht.

W.S. schrieb:
> Leopold N. schrieb:
>> Jemand ne Idee, was ich falsch mache?
>
> Ja, nämlich etwas Grundsätzliches:
>
> Wenn man denn schon Assembler braucht für einen bestimmten Zweck, dann
> schreibt man dafür auch eine Assembler-Quelle und läßt die vom
> zuständigen Assembler zum Objektfile übersetzen. Das linkt man dann zu
> all dem übrigen Zeugs dazu.
>
> Irgendwelche Assembler-Einschübe in eine C Quelle o.ä. mögen ja rein
> technisch möglich und vorgesehen sein, aber ich beurteile so etwas als
> Frickelei, die man besser bleiben lassen sollte.
>
> W.S.

Ich halte es für übertrieben, wegen der zwei bis drei Stellen im Code, 
an denen ich Assembler benötige, extra ein eigenes File dazuzulinken, 
wenn man es auch so erledigen kann.

Grundsätzlich halte ich das nicht für falsch, und ich frage mich, wie du 
dazu kommst, zu entscheiden, was hier richtig und was falsch ist.

Dr. Sommer schrieb:
> W.S. schrieb:
>> Das linkt man dann zu
>> all dem übrigen Zeugs dazu.
>
> Das lässt sich aber dann nicht inlinen und du hast ständig den
> Call-Overhead. Wenn man schon Inline-Assembler nutzt ist Performance
> wahrscheinlich kritisch. Gerade wenn es wie hier anscheinend um ein RTOS
> geht...

Geht um eins, richtig geraten :)

Irgendwie tritt der Fehler auf, wann er Bock hat.
Auch wenn ich keinen einzigen Breakpoint setze, kommt der Fehler 
manchmal.

Im Anhang mal das zugehörige Logfile vom GDB Server, vielleicht kann 
sich ja jemand einen Reim drauf machen.
Single Instruction Mode war aktiviert.
Der Fehler kommt, sobald ich versuche, Inline Assembler zu debuggen. 
Setze ich keinen Breakpoint (oder steppe mit F5) darauf, so scheint es 
zu funktionieren, aber mit stürtzt er ab...

Wenn ich versuche, einen Breakpoint nach dem Assembler Code zu 
platzieren und somit den Assembler Code einfach zu "überspringen", 
stürzt er auch ab.
Und jedes mal, bevor er abstürzt, erscheint folgender Log im der Konsole 
(letzte 5 Zeilen des Anhangs)

Braucht ihr noch irgendwelche Informationen oder hat hier einfach keiner 
eine Idee, was zu tun ist?

Grüße

Stefanus F. schrieb:
> Ich würde mal mit anderen IDEs vergleichen und wenn nur die Cube
> IDE
> (und eventuell Atollic Studio) betroffen ist, dann einen Bug Report
> erstellen.

Ich hatte vorher mit IAR EWARM gearbeitet, da hat der gleiche Code sich 
sehr einfach debuggen lassen.
Ich habe jetzt parallel ein Ticket an ST geschrieben und hoffe, dass die 
wissen, was zu tun ist.

Grüße

Dr. Sommer schrieb:
> Stefanus F. schrieb:
>> Ich würde mal mit anderen IDEs vergleichen
>
> Und mit GDB direkt auf der Konsole, ohne IDE. Ggf auch mal testweise
> ohne die ELF-Datei zu laden, oder eine ELF-Datei ohne Debug-Symbole; im
> Single-Instruction-Modus müsste man das durchsteppen können. Natürlich
> nicht besonders komfortabel...

Ehrlich gesagt weiß ich nicht, wie das geht.
Habt ihr da vielleicht eine Anleitung für mich?

Ganz nebenbei: Ich frage mich, wer sich die liebevolle Mühe macht, jeden 
einzelnen meiner Beiträge downzuvoten. Das ist ja fast schon Belästigung 
:)
Selbst ganz neutrale Beiträge sind davon betroffen...
Aber einen hat er übersehen xD

So,

hab jetzt noch ein bisschen rumprobiert und das Problem entdeckt...es 
saß mal wieder vorm PC.

Ich habe vorher den IWDG initialisiert, und dieser hat mir dann den Chip 
resettet... der IAR hat glaub ich automatisch die entsprechenden Bits im 
DBG Teil manipuliert, deshalb hatte es dort auch so gefunzt.
Habs jetzt manuell im Code gemacht und jetzt läufts.

Vielen Dank für Eure Hilfe

Grüße
Leopold Nützel