Programm in STM32F103 an STM32CubeIDE schläft

[Christoph K. (chriskuku)]

Im Moment weiß ich nicht, worauf ich folgenden Effekt zurückführen muß:

Ich habe (unter macOS BigSur) STM32CubeIDE laufen und daran hängt ein 
Projekt mit STM32F103C8T6 (blue pill) und GNU Hardware debugging 
(blackmagic Dongle). Die Anwendung benutzt FreeRTOS und ich verlasse den 
Aufbau abends mit der Anwendung im Run-Modus. Nach ca. 12h komme ich 
morgens an den Computer, der Screensaver läuft. Meine Hardware hat zwei 
Taster, auf die sie reagiert. Ich drücke die Taster - nichts passiert. 
Nach nochmaligem Drücken der Taster "wacht" die Anwendung auf und 
arbeitet ganz normal.

Jetzt frage ich mich: welcher Umstand versetzt die Anwendung in diesen 
Status? Ist es der Host (STM32CubeIDE)? Ist es die Anwendung selbst im 
STM32F103 (irgendein vorprogrammierter Schlafmodus - power down)? Ein 
Mechanismus in FreeRTOS? Ich habe jetzt noch nicht den Gegenversuch 
gemacht, die Hardware total abzunabeln. Aber in der endgültigen 
Anwendung im Einsatz sollte sie sich natürlich nicht so verhalten, 
sondern immer präsent sein.

[Rahul D. (rahul)]

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?

[Christoph K. (chriskuku)]

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.

[Rahul D. (rahul)]

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

[Christoph K. (chriskuku)]

Rahul D. schrieb:
...
> 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.

[Christoph K. (chriskuku)]

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