STM32CubeIDE Debuggen ohne Flashen, geht das?

Zeus schrieb:
> Gibt es in der IDE die Möglichkeit das Programm zu starten und zu
> debuggen, ohne, dass das Programm jedes Mal geflashed wird?

Nein!

Geht immernoch nicht.

Zeus schrieb:
> Ich muss dies sehr häufig tun, das Projekt ist sehr umfangreich und
> möchte ich dabei nicht immer wieder das Programm auf den µC flashen, da
> der Flash-Speicher auch nur begrenzte Schreibzyklen hat
Ich würde mir an deiner Stelle erst mal keinen Gedanken darum machen. 
Und wenn dann nach einem Jahr tatsächlich das Nucleo zu Tode geflasht 
ist, dann würde ich abwägen, ob ich mir graue Haare um diesen Download 
mache, oder ob mir das einfach egal ist und bis dahin das Nucleo sowieso 
schon einen anderen Tod gestorben ist.

> meines Wissens nach ca. 10k Minimum
Und diese Zahl gilt im Grenztemperaturbereich. Ich habe mit "normalem" 
Programmieren auf dem Schreibtisch noch keinen STM32 kaputt bekommen. 
Lediglich ein Test, der die Schreibzyklen des Flash-Speichers testet, 
bricht nach ca. 15k Durchläufen (im Klimaschrank bei Extremtemperaturen) 
mit einem Fehler ab.

Zeus schrieb:
...
> Gibt es in der IDE die Möglichkeit das Programm zu starten und zu
> debuggen, ohne, dass das Programm jedes Mal geflashed wird?
...
Wenn Code und Daten ins MCU SRAM passen - Linkerscript anpassen und im 
SRAM debuggen. Allerdings ist die Ausführungsgeschwindigkeit, je nach 
Variante, mehr oder weniger anders. Z.B. beim F4->ART.
Zusammengefasst: dieser Ansatz lohnt sich höchstens, wenn man an einem 
kleinen Algorithmus frickelt und einem das FLASH leid tut.

Stichwort FLASH: das stirbt nicht von jetzt auf sofort, vielmehr 
reduziert sich die Retentionszeit nach ein paar tausend Zyklen. Siehe 
Datenblatt. Der Speicherinhalt wird aber auch nach vielen tausend Zyklen 
noch einige Zeit erhalten bleiben.

Da das Evalboard idealerweise sowieso nicht jahrelang laufen muss, ist 
das also kein Grund sich ums FLASH gedanken zu machen.

In den Produktiveinsatz sollten selbstredend nur MCUs gehen, die streng 
nach Datenblatt betrieben werden.

Die einzige produktive Anwendung für Code im SRAM wäre wohl im Bereich 
Firmwareupdate, oder generell bei selbstmodifizierendem Code zu suchen.
Das könnte dann vielleicht ein Algorithmus sein, der sich zur Laufzeit 
selbst optimiert...