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.
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.
:
Bearbeitet durch User
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: ... > 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
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.