Hallo ich habe ein Problem.
Wenn ich auf mein STM32 Nucleo Board ein Programm drauf flashe
funktioniert alles wie es sein soll solange ich die USB Verbindung zum
PC nicht trenne.
Wenn ich die USB Verbindung vom Board zum PC trenne und danach wieder
verbinde läuft das Programm auf dem Board nicht mehr. Ich muss dann
wieder das Programm nochmal über die IDE Workbench auf den Controller
flashen damit es wieder läuft. Und nach dem Flashen läuft es so lange
bis ich die USB Verbindung zum PC nicht trenne.
Ich habe das Gefühl der Controller verliert nach dem Trennen der USB
Verbindung das Programm.
Meine Erwartung ist, der Controller sollte nach dem Trennen der USB
Verbindung und wieder verbinden der USB Verbindung sich neu starten und
weiter laufen.
Viktor schrieb:> Meine Erwartung ist, der Controller sollte nach dem Trennen der USB> Verbindung und wieder verbinden der USB Verbindung sich neu starten und> weiter laufen.
Meine Erwartung ist, dass die Leute den Unterschied zwischen Debug Mode
(Programm läuft nur mit angschlossener Debug Probe, da Breakpoints
gesetzt sind und das Programm evtl sogar nur in den RAM geschrieben
wird) und Release Mode (Programm läuft auch ohne Debug Probe, da fest im
Flash ohne Breakpoints) kennen.
mfg
Felix F. schrieb:> Meine Erwartung ist, dass die Leute den Unterschied zwischen Debug Mode> (Programm läuft nur mit angschlossener Debug Probe, da Breakpoints> gesetzt sind
Quatsch. Die Breakpoints verschwinden bei einem Power-Cycle. Lediglich
Flash-Breakpoints bleiben bestehen, aber die Debugger die die
unterstützen (zB JLink) löschen die auch wieder sofern man das nicht
gerade hart abwürgt.
> und das Programm evtl sogar nur in den RAM geschrieben> wird)
Glaube nicht dass jemand "aus Versehen" das Linker-Script und den
Startup-Code so ändert dass nur in den RAM geschrieben wird...
Der Haupt-Unterschied zwischen Debug & Release sind die Optimierungen.
Man kann auch Relase-Builds debuggen und Debug-Builds ohne Debugger
ausführen.
Dr. Sommer schrieb:> Quatsch. Die Breakpoints verschwinden bei einem Power-Cycle. Lediglich> Flash-Breakpoints bleiben bestehen, aber die Debugger die die> unterstützen (zB JLink) löschen die auch wieder sofern man das nicht> gerade hart abwürgt.
Es gibt Hardware UND Software Breakpoints. Die Software Breakpoints
überschreiben den Code, damit ein Trap für den Debugger ausgelöst wird.
Und diese Breakpoints sind IMMER im Programm, auch ohne Debugger! Und
sehr oft wird ein entsprechender Breakpoint am Einsprungspunkt (der
Main) gesetzt. Dadurch starten viele Programme im Debug Modus nicht.
Dr. Sommer schrieb:> Glaube nicht dass jemand "aus Versehen" das Linker-Script und den> Startup-Code so ändert dass nur in den RAM geschrieben wird...
Meistens wird hier gar nichts umgestellt, da die meisten schon glücklich
sind wenn ihr BlinkyLED läuft und deswegen sind sie auch falsch (für
einen Release Build)
Dr. Sommer schrieb:> Der Haupt-Unterschied zwischen Debug & Release sind die Optimierungen.
UND die Einstellungen wie das Programm auf den Controller kommt!
Am besten du schreibst lieber wieder Artikel in der Bravo ;)
mfg
Felix F. schrieb:> Und diese Breakpoints sind IMMER im Programm, auch ohne Debugger!
Spannend. Und wie kommen die da hinein? Man schreibt jeden Breakpoint
manuell über die "BKPT" Instruktion in den Code?
Also ich mach das immer so: Ich setze in der IDE, während das Programm
schon läuft, über GDB, Breakpoints. Die J-Link Software setzt
automatisch die BKPT Instruktion in den Flash. Wenn ich die
Debug-Session beende macht der J-Link das wieder rückgängig. Das
erklärt, warum ich schon 1000x Debug-Builds geflasht, debuggt und
abgebrochen habe, und sie danach immer noch funktioniert haben (ohne
Debugger!).
Felix F. schrieb:> Und> sehr oft wird ein entsprechender Breakpoint am Einsprungspunkt (der> Main) gesetzt. Dadurch starten viele Programme im Debug Modus nicht.
Meine haben so immer funktioniert.
Felix F. schrieb:> UND die Einstellungen wie das Programm auf den Controller kommt!
Man kann sowohl Debug- als auch Release-Builds z.B. über den GDB oder
auch direkt über ST-Link/J-Link Software flashen, das macht keinen
Unterschied. Man kann sowohl Debug- als auch Release-Builds in den RAM
oder Flash schreiben.
Florian F. schrieb:> Wie steht denn Boot0?
Das ist mal ein sinnvoller Hinweis...
Dr. Sommer schrieb:> Spannend. Und wie kommen die da hinein?
The way software breakpoints work is fairly simple. Speaking about x86
specifically, to set a software breakpoint, the debugger simply writes
an int 3 instruction (opcode 0xCC) over the first byte of the target
instruction. This causes an interrupt 3 to be fired whenever execution
is transferred to the address you set a breakpoint on. When this
happens, the debugger “breaks in” and swaps the 0xCC opcode byte with
the original first byte of the instruction when you set the breakpoint,
so that you can continue execution without hitting the same breakpoint
immediately.
http://www.nynaeve.net/?p=80
mfg
Hmmm... Du widersprichst Dir selbst.
Felix F. schrieb:> Und diese Breakpoints sind IMMER im Programm, auch ohne Debugger!Felix F. schrieb:> the debugger simply writes> an int 3 instruction (opcode 0xCC) over the first byte of the target> instruction.
Was denn nun? Schreibt's nun der Debugger oder was anderes? Wenn
letzteres bleibt die Frage von Dr. Sommer bestehen.
Martin H. schrieb:> Hmmm... Du widersprichst Dir selbst.>> Felix F. schrieb:>> Und diese Breakpoints sind IMMER im Programm, auch ohne Debugger!>> Felix F. schrieb:>> the debugger simply writes>> an int 3 instruction (opcode 0xCC) over the first byte of the target>> instruction.>> Was denn nun? Schreibt's nun der Debugger oder was anderes? Wenn> letzteres bleibt die Frage von Dr. Sommer bestehen.
Der Debugger überschreibt das erste Byte und flasht dann diesen Code.
Somit wird immer der "falsche" Code ausgeführt, der erst durch den
Debugger korrigiert wird. Was ist daran nicht zu verstehen?
Ein "netter" Nebeneffekt ist dabei, dass zum auswechseln von diesem Code
die Pipeline des Prozessors geleert werden muss, wodurch sich die
Performance verschlechert, wenn auch nur um wenige Cycles.
mfg
Mitlesa schrieb:> Felix F. schrieb:>> Speaking about x86 specifically,>> Ohne weitere Worte.
Für die ungebildeten Trolle hier nochmal explizit für ARM:
Software instruction breakpoints
For processors that do not support hardware instruction breakpoints, or
in cases where you have used up all the available hardware breakpoint
resources, you can use software instruction breakpoints. Software
breakpoints modify the instruction in memory to create a special value
that causes the processor to enter debug state when executed. The value
written to memory depends on the processor you are using. For ARM
processors, one of the following schemes is used, depending on the
architecture and processor revision:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0498b/CHDFFICJ.html
mfg
Felix F. schrieb:> Der Debugger überschreibt das erste Byte und flasht dann diesen Code.> Somit wird immer der "falsche" Code ausgeführt, der erst durch den> Debugger korrigiert wird. Was ist daran nicht zu verstehen?
Aha, der Debugger macht das! D.h. wenn ich das Debug-Binary direkt
flashe (ohne Debugger) sind keine Breakpoints drin? D.h. das hat nichts
mit Debug/Release-Build zu tun? (q.e.d)
Und welcher Debugger macht so etwas, und räumt nicht hinter sich wieder
auf, d.h. ersetzt das BKPT nicht wieder durch die richtige Anweisung?
Der J-Link tut das jedenfalls, und der ST-Link kann IIRC sowieso keine
Flash-Breakpoints.
Dr. Sommer schrieb:> Aha, der Debugger macht das! D.h. wenn ich das Debug-Binary direkt> flashe (ohne Debugger) sind keine Breakpoints drin? D.h. das hat nichts> mit Debug/Release-Build zu tun? (q.e.d)
Deshalb sprach ich auch vom Debug MODE, wo das Binary
Debugger-freundlich geflasht wird, deshalb auch DEBUG MODE!
Dr. Sommer schrieb:> Und welcher Debugger macht so etwas
Keiner, aber im DEBUG MODE teilt es die IDE dem Debugger mit, dass er es
so machen soll!
Hast du überhaupt eine Ahnung wie so ein Debug-Prozess funktioniert??
mfg
Ah, jetzt werden wir freundlich.
Ich kenne lediglich deine Wort-Definition von Debug-Mode vs.
Release-Mode nicht. Alle mir bekannten IDE's nutzen das als
Unterscheidung ob ohne bzw. mit Optimierungen und Debug-Informationen
kompiliert wird (also z.B. ob -g -O0 oder -Os -DNDEBUG an den GCC
übergeben wird).
Was ist denn "Debugger-Freundliches" Flashen? Ich übergebe an den
JLink.exe die Option -Freundlich? Und wenn ich die nicht übergebe,
funktionierten die Breakpoints ja anscheinend trotzdem (nach meinem
üblichen Vorgehen). Woher weiß der Debugger beim Debugger-Freundlichen
Flashen überhaupt, wo welche Breakpoints sind? Die kommen doch erst
nachher z.B. über den GDB-Server.
Felix F. schrieb:> Keiner, aber im DEBUG MODE teilt es die IDE dem Debugger mit, dass er es> so machen soll!
Und wie? Ich hab beim JLinkGDBServer.exe noch keine Option
-BehalteFlashBreakpoints gesehen. Noch habe ich jemals so ein Verhalten
beobachtet (wäre ja, wie wir sehen, völlig Banane).
Felix F. schrieb:> Hast du überhaupt eine Ahnung wie so ein Debug-Prozess funktioniert??
Du anscheinend auch nicht.
Zeige doch bitte mal ein reproduzierbares Vorgehen mit J-Link oder
ST-Link, wo du nirgends im Code "BKPT" nutzt, aber dennoch
Flash-Breakpoints im Controller übrig bleiben (sauberes Beenden
vorausgesetzt, kein rabiates Trennen der Stromversorgung/JTAG-Leitung).
Dr. Sommer schrieb:> Zeige doch bitte mal ein reproduzierbares Vorgehen mit J-Link oder> ST-Link, wo du nirgends im Code "BKPT" nutzt, aber dennoch> Flash-Breakpoints im Controller übrig bleiben (sauberes Beenden> vorausgesetzt, kein rabiates Trennen der Stromversorgung/JTAG-Leitung)
Ich hab auf Keil dazu sogar einen Artikel gefunden:
The standard runtime library links in certain low-level debugging
routines, i.e. semihosting functions. Legacy ARM emulators supported
semihosting by responding to the SWIs and BKPTs events. For the
non-debug (released) version of the application, a programmer would
retarget these semihosting functions to non-semihosting equivalents.
http://www.keil.com/support/docs/3614.htm
Und jetzt habe ich keine Lust mehr mit einem Troll zu diskutieren, der
nicht mal die einfachsten Dinge googlen kann und gut gemeinte Ratschläge
mit seinem völlig falschem Halbwissen aufwiegt. Manche sind halt leider
unbelehrbar....
mfg
Felix F. schrieb:> The standard runtime library links in certain low-level debugging> routines, i.e. semihosting functions.
Gut erkannt. Da steht was von "linken". Nicht davon, wie
geflasht/debuggt wird. Es gibt nämlich schlicht und ergreifend kein
Debug/Release-Mode für den Debugger.
In dem Artikel geht es um Semihosting, nicht um Breakpoints. Schlaue
Implementierungen funktionieren auch ohne Debugger. Und normalerweise
merkt man es auch, wenn man Semihosting aktiviert hat...
Felix F. schrieb:> Und jetzt habe ich keine Lust mehr mit einem Troll zu diskutieren, der> nicht mal die einfachsten Dinge googlen kann und gut gemeinte Ratschläge> mit seinem völlig falschem Halbwissen aufwiegt. Manche sind halt leider> unbelehrbar....
Ah, wenn man widerlegt wurde bezeichnet man den anderen einfach als
Troll!
Also ich arbeite schon einige Jahre mit STM32 und habe auch schon viel
debuggt und geflasht sowie mich mit den Details der Toolchain
auseinander gesetzt. Ich habe im JLink Manual noch keine -Freundlich
Option gefunden und auch noch nie gesehen, dass Flash-Breakpoints im
Controller verbleiben. Statt zu Flamen könntest du ja einfach zeigen wo
dein "Debugger-freundlich"-Modus herkommt!
Habe ich es hier schon mal erwähnt: ST-Link updaten !
"Both Nucleo 64 boards ( F401RE and L476RG ) are working now as they are
expected ( from my side ;) )
The problem of the F401RE with the "mass storage download" was an
on-board ST-LINK V2 proplem: I had to update it with the "STM32 ST-LINK
Utility" then it was working correct."
Dr. Sommer schrieb:> Ah, wenn man widerlegt wurde bezeichnet man den anderen einfach als> Troll!
Was hast du denn widerlegt kleiner Sommertroll?? Im gegensatz zu dir
hinterlege ich meine Aussagen mit vernünftigen Quellen. Von dir kam nur
heiße Luft, und davon gibt es aktuell schon genung...
Dr. Sommer schrieb:> Gut erkannt. Da steht was von "linken". Nicht davon, wie> geflasht/debuggt wird. Es gibt nämlich schlicht und ergreifend kein> Debug/Release-Mode für den Debugger.> In dem Artikel geht es um Semihosting, nicht um Breakpoints. Schlaue> Implementierungen funktionieren auch ohne Debugger. Und normalerweise> merkt man es auch, wenn man Semihosting aktiviert hat...
Seit wann geht es hier um Breakpoints?? Es geht hier darum, dass das
Programm nicht startet und da kann Semihosting genauso schuld sein.
Breakpoints waren nur mein erster Einfall. Also lenke nicht schon wieder
vom Thema ab!
Dr. Sommer schrieb:> Also ich arbeite schon einige Jahre mit STM32 und habe auch schon viel> debuggt und geflasht sowie mich mit den Details der Toolchain> auseinander gesetzt. Ich habe im JLink Manual noch keine -Freundlich> Option gefunden und auch noch nie gesehen, dass Flash-Breakpoints im> Controller verbleiben. Statt zu Flamen könntest du ja einfach zeigen wo> dein "Debugger-freundlich"-Modus herkommt!
Die Segger Toolchain ist doch ein Abklatsch von Crossworks. Also eine
All-in-One IDE für Leute ohne wirklich Ahnung, da prinzipiell alles
geregelt wird, deshalb funktioniert es auch bei dir tadellos. Und hier
sieht man auch, dass du dich eben nicht mit dem ganzen Debug-Prozess
befasst hast, sondern nur Knöpfchen auf vorgefertigten IDEs drücken
kannst.
Markus schrieb:> Habe ich es hier schon mal erwähnt: ST-Link updaten !>> "Both Nucleo 64 boards ( F401RE and L476RG ) are working now as they are> expected ( from my side ;) )> The problem of the F401RE with the "mass storage download" was an> on-board ST-LINK V2 proplem: I had to update it with the "STM32 ST-LINK> Utility" then it was working correct."
Das wird dem TE nichts bringen! Er muss sein Programm korrekt flashen!
mfg
Felix F. schrieb:> Im gegensatz zu dir> hinterlege ich meine Aussagen mit vernünftigen Quellen. Von dir kam nur> heiße Luft, und davon gibt es aktuell schon genung...
ALso hier nochmal schriftlich:
https://www.segger.com/downloads/jlink/UM08001_JLink.pdf
Hier ist das User Manual vom J-Link. Ich finde da kein
"Debugging-Freundliches" Flashen.
Dass die Breakpoints automatisch wieder gelöscht werden steht da leider
tatsächlich nicht, aber das kann man ja leicht ausprobieren.
Zeige du doch mal eine Quelle, wo der "Debug/Release-Mode" beim
Debuggen dokumentiert ist.
Felix F. schrieb:> Seit wann geht es hier um Breakpoints??
Seit deinem 1. Beitrag:
Felix F. schrieb:> (Programm läuft nur mit angschlossener Debug Probe, da Breakpoints> gesetzt sindFelix F. schrieb:> Es geht hier darum, dass das> Programm nicht startet und da kann Semihosting genauso schuld sein.
Das kann wirklich sein. Aber das hat wenn schon was mit
Debug/Release-Builds zu tun (Quelle hast du ja selbst gefunden), und
nicht mit Debug/Relase "Debugging Modes", den es nicht gibt (siehe
JLink-Manual).
Felix F. schrieb:> deshalb funktioniert es auch bei dir tadellos
Die benutze ich überhaupt nicht.
Felix F. schrieb:> Und hier> sieht man auch, dass du dich eben nicht mit dem ganzen Debug-Prozess> befasst hast, sondern nur Knöpfchen auf vorgefertigten IDEs drücken> kannst.
Woher weißt du das jetzt wieder? Ich arbeite zwar meistens mit eclipse,
aber ich habe auch schon direkt auf der Konsole mit JLinkGDBServer,
arm-none-eabi-gdb und GCC gearbeitet und auch mit den
ST-Link-Äquivalenten und weiß daher durchaus wie das funktioniert. Da
gibt es jedenfalls keine Option für Debugging-Freundliches Flashen.
Dr. Sommer schrieb:> ALso hier nochmal schriftlich:> https://www.segger.com/downloads/jlink/UM08001_JLink.pdf> Hier ist das User Manual vom J-Link. Ich finde da kein> "Debugging-Freundliches" Flashen.> Dass die Breakpoints automatisch wieder gelöscht werden steht da leider> tatsächlich nicht, aber das kann man ja leicht ausprobieren.>> Zeige du doch mal eine Quelle, wo der "Debug/Release-Mode" beim> Debuggen dokumentiert ist.
Da ein Nucleo Board einen ST-Link eingebaut hat, sind diese Infos
ziemlich wertlos. An Umschreibungen wie "Debug-freundlich" ziehen sich
übrigens nur Sommertrolle auf ;)
Dr. Sommer schrieb:> Seit deinem 1. Beitrag:
Hier gehts aber um den 1. Beitrag des TEs, und da geht es um "nicht
starten".
Dr. Sommer schrieb:> Das kann wirklich sein. Aber das hat wenn schon was mit> Debug/Release-Builds zu tun (Quelle hast du ja selbst gefunden), und> nicht mit Debug/Relase "Debugging Modes", den es nicht gibt (siehe> JLink-Manual).
Debug-Build + Grüner Pfeil = Debugging Mode = Mit Debug-Informationen
modifiziertes Programm = im Normalfall nicht ohne Debugger lauffähig
Zum 2. mal: JLink ist hier völlig uninteressant das ST-Link
Dr. Sommer schrieb:> Debugging-Freundliches Flashen.
Sommertroll??
Ich bleibe dabei, der TE hat einen Debug-Build erzeugt und hat dann eine
Debug-Session gestartet, die einen Debugger zur Ausführung benötigt.
Evtl. ist das Programm auch im RAM gelandet.
mfg
Felix F. schrieb:> An Umschreibungen wie "Debug-freundlich" ziehen sich> übrigens nur Sommertrolle auf ;)
Dann erläutere doch mal, was du damit eigentlich meinst. Das bist du uns
bis jetzt schuldig geblieben. Du erzählst von Funktionen eines Debuggers
die einfach nicht existieren, und wenn man nachbohrt wirfst du nur noch
mit Beleidigungen um dich. Top Diskussionverhalten.
Felix F. schrieb:> Hier gehts aber um den 1. Beitrag des TEs, und da geht es um "nicht> starten".
Jaja, jetzt noch schnell Rückzieher machen und den eigenen Unfug als
unwichtig wegwischen.
Felix F. schrieb:> Debug-Build + Grüner Pfeil = Debugging Mode = Mit Debug-Informationen> modifiziertes Programm = im Normalfall nicht ohne Debugger lauffähig
Die Debug-Informationen landen überhaupt nicht im Flash, sondern nur in
der ELF-Datei.
Im Allgemeinen ist das sehr wohl lauffähig (viele Programme sind sogar
nur so lauffähig, weil die Leute nichtdefiniertes Verhalten von C/C++
ausnutzen welches im Release-Modus des Compilers kaputtoptimiert wird).
Nur wenn man eine dumme Semihosting-Implementation nutzt, evtl nicht.
Felix F. schrieb:> Ich bleibe dabei, der TE hat einen Debug-Build erzeugt und hat dann eine> Debug-Session gestartet, die einen Debugger zur Ausführung benötigt.
Das hat auch niemand bezweifelt.
Felix F. schrieb:> Sommertroll??
Damit hast DU angefangen, ohne es belegen zu können! Wenn du nicht
diskutieren möchtest, schreibe vielleicht einfach keine frei erfundenen
Fakten?
Dr. Sommer schrieb:> Die Debug-Informationen landen überhaupt nicht im Flash, sondern nur in> der ELF-Datei.
OK, hier habe ich mich wirklich falsch ausgedrückt. Es sind keine
Debug-Infos im Code, sondern nur Modifizierungen im Code die dann z.B.
Traps, Interrupts etc. auslösen, die dann der Debugger auffängt und
verarbeitet.
Dr. Sommer schrieb:> Du erzählst von Funktionen eines Debuggers> die einfach nicht existieren, und wenn man nachbohrt wirfst du nur noch> mit Beleidigungen um dich. Top Diskussionverhalten.
Softwareinterrupts und Traps zur Behandlung von Breakpoints und
Interrupts sind z.B. solche Funktionen. Wie soll der Debugger sonst
debuggen?
mfg
Felix F. schrieb:> Debug-Build + Grüner Pfeil = Debugging Mode
Du kennst dich also auch nur mit bunten Knöpfen aus und weißt nicht was
im Hintergrund passiert ;-)
Felix F. schrieb:> Softwareinterrupts und Traps zur Behandlung von Breakpoints und> Interrupts sind z.B. solche Funktionen. Wie soll der Debugger sonst> debuggen?
Diese Funktion ist im Debugger aber immer aktiv. Dazu braucht es
keinen "Debug-MODE", wie du es behauptest:
Felix F. schrieb:> Deshalb sprach ich auch vom Debug MODE, wo das Binary> Debugger-freundlich geflasht wird, deshalb auch DEBUG MODE!
Und diese Funktionen werden, wie gesagt, bei sauberer Beendigung der
Session wieder deaktiviert. Sind daher nicht Grund für das Problem.
Ich habe vorhin die JLink Doku bemüht weil der ST-Link ja keinen eigenen
GDB-Server mitbringt. Aber du darfst gerne auch im Manual vom ST-Link
oder der zugehörigen GDB-Server von texane/OpenOCD/Atollic den
sagenumwobenene "Debug MODE" zeigen.
Hallo Leute,
danke für die vielen Vorschläge. Ich habe Gestern das Problem gefunden.
Es gibt einen Bug im onBoard ST-Link auf dem Board Nucleo F401RE.
Man muss nur den OnBoard ST-Link updaten und das Problem verschwindet
danach. Das Problem hatte nichts mit Debug oder Release Mode zu tun
gehabt. Ich habe auch alle Einstellungen im Workbench so gelassen wie
die waren und nach dem Update des OnBoard ST-Link verschwand das
Problem.
Ich habe den OnBoard ST-Link über das Programm ST-LINK Utility
geupdatet.
Viktor schrieb:> Es gibt einen Bug im onBoard ST-Link auf dem Board Nucleo F401RE.>> Man muss nur den OnBoard ST-Link updaten
Hallo Viktor,
hast Du evtl. einen Link dazu?
>Man muss nur den OnBoard ST-Link updaten und das Problem verschwindet>danach.
Das habe ich hier in diesem Thread schon zwei mal geschrieben, aber Ihr
wolltet euch ja lieber streiten ...
Können wir uns drauf einigen, dass Felix F. offensichtlich Keil (uVision
?) verwendet, bei dem im "Debug-Mode" wohl ein immer Software-Breakpoint
eingebaut wird (von wem auch immer) und das resultierende Binary nicht
ohne Debugger lauffähig ist?
Der vermutlich deutlich größere Teil der Forumsteilnehmer wird irgendwas
auf eclipse und gcc basierendes benutzen, bei dem der "Debug Mode"
lediglich die Compiler-Settings beeinflusst. Das resultierende Binary
ist uneingeschränkt verwendbar.
