STM32 Cube IDE Inline Assembler

[Leopold N. (leo_n)]

Hallo,

wenn ich in der STM32 Cube IDE Inline Assembler wie im Anhang debuggen 
möchte, gibt der Debugger eine Fehlermeldung aus (Anhang).
Der selbe Code hat in der IAR Embedded Workbench problemlos 
funktioniert, beim Compilieren, etc... gibt es in der Cube IDE keine 
Probleme, erst beim Debuggen.
An der Anzahl der Breakpoints kann es nicht liegen (siehe Anhang)

Jemand ne Idee, was ich falsch mache?

Edit: Sry für 2mal das gleiche Bild...

[Stefan F. (Gast)]

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

[Dr. Sommer (Gast)]

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.

[Leopold N. (leo_n)]

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

[Leopold N. (leo_n)]

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?

[Stefan F. (Gast)]

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.

[Leopold N. (leo_n)]

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 (Gast)]

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

[Leopold N. (leo_n)]

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 (Gast)]

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)

[Leopold N. (leo_n)]

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.

[Vincent H. (vinci)]

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?

[W.S. (Gast)]

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.

[Dr. Sommer (Gast)]

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

[Leopold N. (leo_n)]

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.

[Leopold N. (leo_n)]

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

[Stefan F. (Gast)]

Wenn ich eine Funktion oder ein Makro an 5 Stellen inline und darauf 
einen Unterbrechungspunkt setze, dann habe ich praktisch schon 5 
Unterbrechungspunkte verbraucht - denke ich.

[Leopold N. (leo_n)]

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

[Leopold N. (leo_n)]

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

[Leopold N. (leo_n)]

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)

[Leopold N. (leo_n)]

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

Grüße

[Stefan F. (Gast)]

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.

[Leopold N. (leo_n)]

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

[W.S. (Gast)]

Leopold N. schrieb:
> 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.

Erstens: Wenn du 3 Stellen hast, wo du meinst, Assembler in C zu 
brauchen, dann brauchst du entweder gar kein Assembler oder du 
bräuchtest tatsächlich ja doch eine separate Assemblerquelle.

Zweitens: Ich frage dich, wie du dazu kommst, zu behaupten, daß ich hier 
enrschiede, was richtig oder falsch sei. Was der Compiler zu übersetzen 
vermag, ist offenbar so richtig, daß es nicht gegen die Regeln verstößt. 
genau das hab ich die auch geschrieben. Aber Frickelei ist und bleibt 
es dennoch.

Und drittens: ich vermute hier mal (ja, nur ne Vermutung), daß der GCC 
sich bei Assembler-Inlines usw. mal wieder ne Extrawurst brät oder das 
Ganze eine Spracherweiterung des GCC ist, die zu einer gleichlautenden 
Erweiterung bei IAR nicht wirklich kompatibel ist. Vielleicht hast du da 
nur einen winzigen Kringel irgendwo übersehen. Aber genau SOLCHE 
Probleme sind eben Inhalt und Folge von Frickelei.

Warum versuchst du denn nicht, deine Quellen frei zu halten von 
irgendwelchen Lockin's? Also von ST oder GCC oder irgend sowas. Genau 
das, was du anfangs als "wenn man es auch so erledigen kann" angesehen 
hast, macht dir jetzt ein Zusatzproblem.

W.S.

[Dr. Sommer (Gast)]

W.S. schrieb:
> dann brauchst du entweder gar kein Assembler oder du
> bräuchtest tatsächlich ja doch eine separate Assemblerquelle.

Wie kommst du darauf? Ohne Assembler kein RTOS. Mit extra 
Assembler-Quelle kein Inlining. Oder ist das eine deiner Privat-Regeln, 
Herr Beckmesser?

W.S. schrieb:
> Was der Compiler zu übersetzen
> vermag, ist offenbar so richtig, daß es nicht gegen die Regeln verstößt.

Ja, der Code sieht i.O. aus.

W.S. schrieb:
> Aber Frickelei ist und bleibt
> es dennoch.

Das sind Kernel immer.

W.S. schrieb:
> Und drittens: ich vermute hier mal (ja, nur ne Vermutung), daß der GCC
> sich bei Assembler-Inlines usw. mal wieder ne Extrawurst brät oder das
> Ganze eine Spracherweiterung des GCC ist

Natürlich ist es das. Der C-Standard definiert keinen Inline-Assembler.

W.S. schrieb:
> die zu einer gleichlautenden
> Erweiterung bei IAR nicht wirklich kompatibel ist

Wieso sollte sie auch - was der IAR für richtig hält, ist nicht 
C-Standard.

W.S. schrieb:
> Warum versuchst du denn nicht, deine Quellen frei zu halten von
> irgendwelchen Lockin's?

Weil man einen RTOS-Kernel nicht ohne plattformspezifischen Code 
schreiben kann.

Eine externe Assembler-Quelle ist auch nicht C-Standard-kompatibel oder 
portabel. Inline-Assembler ist im Bare-Metal-Embedded-Bereich und bei 
Kerneln wie Linux absolut üblich. Oder benutzt du für Dinge wie "WFI" 
oder "DSB" auch externe Funktionen? Sodass dann sinnlos 5-6 
Register-Sicherungen und Sprünge durchgeführt werden müssen? Selbst in 
der CMSIS sind diese als Inline-Assembler.

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

[Leopold N. (leo_n)]

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

[Leopold N. (leo_n)]

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