Programm in STM32F103 an STM32CubeIDE schläft

Christoph K. schrieb:

Welcher Umstand versetzt die Anwendung in diesen Status?

Meine Vermutung: Dein PC legt sich schlafen und schaltet die Verbindung zur Debugging Hardware ab, um Strom zu sparen.

Testbetrieb mit angeschlossenem Debugger ist doch sowieso unpraktisch,oder lieferst du den Aufbau so mit zum Kunden?

Rahul D. schrieb:

Christoph K. schrieb:

Welcher Umstand versetzt die Anwendung in diesen Status?

Meine Vermutung: Dein PC legt sich schlafen und schaltet die Verbindung zur Debugging Hardware ab, um Strom zu sparen.

Ja, das war auch meine erste Vermutung, aber ich verstehe nicht ganz den Mechanismus, wenn STM32CubeIDE schläft, warum wirkt sich das auf die Anwendung im Target aus? Welches Signal oder welcher Pin wirkt auf das Target, daß es stoppt bzw. in welchem Zustand ist das Target dann?

Testbetrieb mit angeschlossenem Debugger ist doch sowieso unpraktisch,oder lieferst du den Aufbau so mit zum Kunden?

Die letzte Frage erübrigt sich doch von selbst. Das ist mal wieder so eine der üblichen Spitzen, die einen hier erwarten.

Christoph K. schrieb:

Welches Signal oder welcher Pin wirkt auf das Target, daß es stoppt bzw. in welchem Zustand ist das Target dann?

Beim Debuggen kann man den Controller anhalten. Wie verhälkt sich dein Programmer/Debugger, wenn du ihn von der (USB?-) Schnittstelle abziehst, aber am Controller lässt? Wenn ich meinen PC runterfahre und den Programmer (ST-Link) am Controller hängen lasse, wird der Controller dauerhaft resetet.

Christoph K. schrieb:

Die letzte Frage erübrigt sich doch von selbst. Das ist mal wieder so eine der üblichen Spitzen, die einen hier erwarten.

Nö. STM liefert seine NUCLEO-Boards auch mit einem (integrierten) Programmer aus. Die Frage zielte auf deine Testmethode ab: Wie würdest du feststellen, dass dein Board noch das macht, was es soll, wenn kein Debugger dranhängt? Wie stellt man fest, dass es eben nicht mehr das macht, was es soll? Es gab schonb Fälle, bei denen beim Kunden ein Problem auftrat, im Labor aber nicht. Mit dem Ergebnis, dass im Labor ein Messgerät dranhing, das eine notwendige Belastung hervorrief, die beim Kunden nicht vorhanden war. Dämliches Design...

Rahul D. schrieb im Beitrag #7393249: ...

Die Frage zielte auf deine Testmethode ab: Wie würdest du feststellen, dass dein Board noch das macht, was es soll, wenn kein Debugger dranhängt?

Gut, stattgegeben. Bin ja noch in der Entwicklungsphase. Die Fieldtestphase steht natürlich noch aus. Und das natürlich stand-alone.

Gelöst!

Es war eine Komponente in meinem Aufbau, die anscheinend "schlafen geht". Dank eines Tipps von Harry habe ich eine Task eingebaut, die alle 5s mal kurz die LED flasht. Die lief und lief, auch nach 12h. Also ging der STM32F103 offenbar nicht schlafen, wohl aber das Scanmodul PEDSCAN, das ich benutze. Das hat einen PIC16F577 drauf.

Die beiden Testbuttons, die ich dann immer drückte, hingen direkt an dem Scanmodul und es wurde dadurch wohl aufgeweckt. Habe den Autor jetzt mal gefragt, ob und warum er das macht. Noch keine Antwort, aber es wird wohl so sein. Das ganze hatte also nichts zu tun mit STM32CubeIDE, macOS Schlafmodus, oder FreeRTOS (Heapsize oder anderen Resource-Engpässen). Danke noch mal für's Mitlesen.

Schöne Woche, Christoph