IAR EW for ARM - Debug vs. Release

[Tom W. (nericoh)]

Hallo Gemeinde :)

Ich würde gerne besser (bzw überhaupt mal) verstehen, wie sich die 
beiden Default-Buildprofile "Release" und "Debug" der IAR Embedded 
Workbench voneinander unterscheiden.

Hierzu folgendes Minimal-Szenario (getestet mit IAR EW for ARM in 
Version 7.40 und 7.70):

ich erstelle ein neues Projekt
Project -> Create New Project -> Tollchain "ARM"; Project-Templates C

-> nun habe ich ein neues Projekt mit main.c, die lediglich

int main()
{
  return 0;
}

enthält.

Da ich aktuell nur über eine IAR-Lizenz für Cortex-Kerne verfüge, wähle 
ich anschließend noch in den Projektoptionen unter "General Options" 
einen Cortex-M0 als Zielarchitektur aus, alle anderen Settings belasse 
ich auf Default.

Standartmäßig steht das Build-Profil auf "Debug". Klicke ich nun auf den 
"Download and Debug"-Button, wird meinen Mini-Projekt übersetzt etc und 
in den Simulator geladen (alternativ kann ich natürlich auch einen 
konkreten uC + Debugger, z.B. LPC11U35 oder STM32F0xx jeweils  über SWD 
mit JLINK als Debug-Probe angebunden auswählen - ändert nichts am 
Ergebnis).

IAR erstellt automatisch einen Breakpoint am Anfang von main() und 
wartet dort darauf, dass mit Klick auf "Go" (oder steppen durch die 
Anweisungen) "loslaufe".

Soweit so gut.

Wähle ich nun das "Realease"-Buildprofil aus, wähle hierfür ebenfalls 
den M0 als Zielarchitektur und klicke auf "Download and Debug", popt ein 
Fenster mit der Fehlermeldung "The stack plug-in failed to set a 
breakpoint on 'main'. The Stack window will not be able to display stack 
contents. (You can change this setting in the Tool>Options dialog box.)"

In dem genannten Optionsdialog finde ich jedoch keine Einstellung, die 
die Fehlermeldung erklären würde - insbesondere unterscheiden sich die 
Einstellungen dort nicht von denen, die auch im Debug-Buildprofil dort 
eingestellt sind.

Vergleiche ich die Projekteinstellungen, die IAR für die beiden 
Buildprofile vornimmt, konnte ich lediglich bei der Compileroptimierung 
einen Unterschied feststellen:
beim Debug-Profil steht die Compiler-Optimierung auf "Low", bei Release 
auf "High (Balanced)". Selbst wenn ich probehalber die 
Compileroptimierung für "Release" ebenfalls auf "Low" stelle, ändert 
sich das geschilderte Verhalten nicht.

Daraus schließe ich, dass sich diese beiden Build-Profile noch an einer 
weiteren (offenbar entscheidenden Stelle) voneinander unterscheiden 
müssen - weiß jemand etwas dazu oder kann mir zumindest einen Hinweis 
geben, wo in der IAR-Doku (oder anderen Quellen) sich dazu etwas 
nachlesen lässt (ich habe bisher nichts dazu finden können).

Ich stelle die Frage hier nicht, weil ich das als akutes Problem lösen 
muss - ich würde nur gerne den Zusammenhang verstehen, weil ich offenbar 
noch diverse Wissenlücken habe, was grundsätzlich beim Debuggen, setzen 
von Breakpoints etc passiert und welche Aspekte dabei eine Rolle spielen 
(auch ganz unabhängig von der konkreten Toolchain).

Gruß,
Tom

[Lothar (Gast)]

Bei den Cortex-M gibt es (wenige) Hardware-Breakpoints sowie einen 
Breakpoint-Assembler-Befehl BKPT

Für Release und Debug gibt es dazu mehrere Einstellungen, grundsätzlich 
gilt aber: Wenn im Debug mehrere Breakpoint benötigt werden als in 
Hardware vorhanden, also BKPT verwendet wird, ist Debug nicht mehr ohne 
Debugger lauffähig. Debug ist durch die zusätzlichen Instruktionen auch 
größer als Release.

https://www.iar.com/support/resources/articles/making-the-best-use-of-the-available-breakpoints/

https://www.iar.com/support/tech-notes/debugger/application-does-not-run-stand-alone/

[Tom W. (nericoh)]

Danke für die Hinweise - werde dort mal nachlesen

[Jim M. (turboj)]

Tom W. schrieb:
> -> nun habe ich ein neues Projekt mit main.c, die lediglich
> int main()
> {
>   return 0;
> }

Gaaanz schlecht auf einem µC. Dort muss mindestens eine Endlosschleife 
in main() sein, also

int main()
{ 
  while (1);
  return 0;
}

Dann optimiert der C-Compiler die Funktion auch nicht weg...

[--- (Gast)]

> Gaaanz schlecht auf einem µC.

Quatsch.

Jede ordentliche Runtime packt die main() in eine while-Schleife.

runtimeblablub:
while (1)}
{
  main();
}

Wenn Mann das nicht will, muss Mann es explizit verhindern.
(z.B. mit einer while- oder for-Schleife.)
Ansonsten startet die Runtime die main-Funktion einfach
wieder neu.

[Mike R. (thesealion)]

--- schrieb:
>> Gaaanz schlecht auf einem µC.
>
> Quatsch.
>
> Jede ordentliche Runtime packt die main() in eine while-Schleife.
>
>

> runtimeblablub:
> while (1)}
> {
>   main();
> }
>

>

Von was für einer Runtime redest du hier? Ich hab bei diversen Compilern 
noch nie gesehen, das die eine while Schleife um mein Programm erzeugt 
hätten.

[Steffen R. (steffen_rose)]

--- schrieb:
> Ansonsten startet die Runtime die main-Funktion einfach
> wieder neu.

Ohne den Speicher neu zu initialisieren? Ganz schlechte Lösung.
Konkret machen es die verschiedenen Hersteller sehr unterschiedlich. 
Endweder bleiben sie nach Verlassen in einer Endlosschleife hängen oder 
starten über einen Reset/Trap neu. Die von Dir angesprochene Lösung habe 
ich bisher noch nie gesehen.

[CPP (Gast)]

Für die Cortex M4 Controler von Atmel (Atmel Studio 7) ist auch der 
Startup Code in C geschrieben und dort ist eine Endloschleife nach 
beenden der main function implementiert

[CPP (Gast)]

Um aber auf die Frage des TE zurück zu kommen.

In aller Regel macht die IDE von sich aus keine Unterschiede. "Release" 
und "Debug" sind quasi nur zwei unterschiedliche Project-Settings. Und 
was dort Default mäßig unterschiedlich eingestellt ist kann man in den 
Settings nachschauen. (Entweder durch die Dialoge oder durch Analyse der 
EWP Datei)

Ich persönlich nutze immer ausschließlich die "Debug" Variante, da es 
mir zu Aufwändig ist mehr als ein Projekt-Setting zu pflegen.

Andererseits ist aber möglich weitere Settings einem Project 
hinzuzufügen. Um zum Beispiel zusätzlich noch Unit Tests mit aufzunehmen