Hi, laut STM32G0xx Datenblatt hat der Debugger die Möglichkeit den Watchdog anzuhalten (DBG APB freeze register 1). Das wäre eine prima Möglichkeit, auch mit aktivem WatchDog zu debuggen. Nur finde ich unter Verwendung des ST-Link dazu keine Einstellmöglichkeit. Habe ich da was übersehen oder wird das von der CubeIDE nicht unterstützt oder ist nur mit dem SEGGER J-Link möglich? Gruß Ingo
Bei meinem L451 kann ich das Bit einfach wie jedes andere setzen. Die Frage ist nur, wie Register und Bit bei dir heißen. Aber Bit 11 oder 12 für den WWDG bzw. IWDG im DBG APB freeze register 1 ist eigentlich eindeutig. Anders gesagt: das muss ja nicht der Debugger machen, eine Zeile am Anfang von main() sollte auch reichen.
Danke, ich habe das mal ausprobiert, es lässt sich nicht per code setzen. LL_DBGMCU_APB1_GRP1_FreezePeriph(LL_DBGMCU_APB1_GRP1_IWDG_STOP); Leider stimmt die Datenblatt Einschränkung: "It can be written by the debugger under system reset." der Zusatz: "it is still possible to write this register by software." fehlt bim STM32G0xx leider.
Kannst ja mal versuchen, ob im Debug Fenster unter SFRs -> IWDG irgend etwas änderbar ist.
Einfache Register, wie GPIOn lassen sich zwar nicht beim Debug Start at main() ändern, aber nach dem GPIO_Init(), das könnte am fehlenden Clock liegen. Das freeze register lässt sich leider nicht ändern, bzw. man kann zwar einen Wert eintragen, der aber beim Abschluss der Eingabe wieder gelöscht wird.
ich weiss nicht ob das beim M0+ auch geht, aber beim M3/M4/M7 kannst Du in deiner Firmware herausfinden, ob ein Debugger angeschlossen ist (bit 0 im DHCSR Register), damit kannst Du zum Startup entscheiden, ob der Watchdog aktiv sein soll oder nicht. Funktioniert wunderbar bei uns...
Zur Not kann man den Wachhund und alles was er so braucht in ein einfaches #ifdef einsperren.
Klar, das geht immer. Die dynamische Variante hat aber den Charme, dass sich die Release Version (notfalls im Feld) debuggen lässt, ohne eine Debug Firmware einspielen zu müssen.
Wer einen Debugger benötigt kann nicht programmieren. Such dir ein anderes Hobby.
Das mit dem #ifdef habe ich bisher gemacht, ist ja auch kein Problem. Mir ist nur aufgefallen, das man ja auch ganz gezielt andere Timer beim debuggen anhalten kann. Das könnte ja mal in speziellen Fällen hilfreich sein, wenn man dann die Information direkt zur Umsetzung zur Verfügung hat und nicht mühsam suchen muss. Im Moment habe ich da kein Problem, aber vorher schlau machen für den Fall des es mal hilfreich ist, ist ja nicht verkehrt. Auf der embedded sollte man die fehlende Info bekommen können.
Haha schrieb: > Wer einen Debugger benötigt kann nicht programmieren. Such dir ein > anderes Hobby. Ja. Und wer eine Wasserwaage braucht um ein Regal aufzuhängen hat nen Knick in der Optik, wer einen Bagger benutzt um ein Loch zu graben ist nur zu faul zum Schaufeln, wer ein Mikroskop zur Sichtkontrolle von 0201 benötigt sollte mal mit seinem Augenarzt sprechen, wer Qualitätssicherung betreibt hat einfach nur seine Produktion nicht im Griff und wer einen Schraubendreher braucht um Schlitzschrauben festzuziehen sollte lieber mal rausfinden warum die Fingernägel so brüchig sind, Vielleicht liegts an der Ernährung?
Bernd K. schrieb: > Ja. Und wer eine Wasserwaage braucht um ein Regal aufzuhängen hat nen > Knick in der Optik Die Diskussion hatten wir ja erst kürzlich und alles wurde widerlegt. Hier nachzulesen, warum ein Debugger nur was für Anfänger ist: Beitrag "Re: Weg von Arduino - Beratung"
Haha schrieb: > Wer einen Debugger benötigt kann nicht programmieren. Such dir ein > anderes Hobby. Dazu auch interessant, wieso Torvalds und Robert C. Martin keine Debugger mögen: https://lwn.net/2000/0914/a/lt-debugger.php3 https://www.artima.com/weblogs/viewpost.jsp?thread=23476 Aber klar, wer sich erstmal von nem Debugger abhängig gemacht hat, kann sich gar nicht mehr vorstellen, ohne zu arbeiten und kommt sich damit wahrscheinlich auch noch professionell vor.
Die Notwendigkeit hängt doch auch vom Projekt ab. Hier geht es doch nicht um Betriebssysteme oder deren Anwendungen, sondern um uControler in realtime Anwendungen, die oft nicht mal eine freie Schnittstelle für ein Logging bieten. Da bin ich froh, wenigstens mal einen Breakpoint setzen zu können, um mir interne Zustände ansehen zu können.
Ingo S. schrieb: > Da bin ich froh, wenigstens mal einen Breakpoint setzen zu können, um > mir interne Zustände ansehen zu können. Da sind große Datenmengen in Form von Logging über eine Uart besser geeignet als Debugging. Muss man halt einplanen.
Heh, erst lesen, dann Antworten. Logging ohne freie Schnittstelle per Gedankenübertragung?
Ingo S. schrieb: > ogging ohne freie Schnittstelle per Gedankenübertragung? Designfehler, schlechte Planung. Lieber auf Debugger verzichten und stattdessen eine UART nach außen führen. Kein guter Programmierer braucht einen Debugger.
Haha schrieb: > > Designfehler, schlechte Planung. Lieber auf Debugger verzichten und > stattdessen eine UART nach außen führen. Kein guter Programmierer > braucht einen Debugger. Achso, aber jeden Sch... auf einer Loggingschnittstelle auszugeben macht einen guten Programmierer?
Haha schrieb: > Designfehler, schlechte Planung. Lieber auf Debugger verzichten und > stattdessen eine UART nach außen führen. Kein guter Programmierer > braucht einen Debugger. Was für ein Bullshit! Und griffbereit in der Schublade dann auch immer gleich die Neunschwänzige zur stündlichen Selbstgeiselung bereitliegen haben oder was?
Was ist wenn UART zu lahm? Schonmal was von coverage + tracing gehört?
ITM debugging/streaming? Profiling?
Das läuft nicht ohne debugger.
@topic,
Das ist eigentlich unabhängig vom Debugger. Wir haben den Watchdog immer
eingeschaltet, damit man nicht auf blöde Gedanken kommt. Beim STM32F103
(ich weiß, andere MCU) geht das über das DBGMCU -> CR Register. Da muss
man z.B. das Bit 8 ("DBGMCU_CR_DBG_IWDG_STOP") setzen, damit der
watchdog auch anhält, wenn die MCU im Stopp mode ist und das
funktioniert.
Manchmal möchte die IDE aber auch solche Sachen überschreiben, gbits da
vielleicht Optionen beim Debugger? Wenn ja alles ausschalten und per
Sofwtare das Bit setzen.
Ich sehe gerade, das gibts beim STM32G0x1 auch:
https://www.st.com/content/ccc/resource/technical/document/reference_manual/group0/2f/21/cb/33/78/80/42/64/DM00371828/files/DM00371828.pdf/jcr:content/translations/en.DM00371828.pdf
Abschnitt 37.9.2 und später. Heißt wie du sagst allerdings DBG_APB_FZ1
und nicht CR. Wenn du bit 12 setzt, resettet er trotz vom Debugger
gestoppten Core?
edit: scheiße du hast Recht. Kann nur vom Debugger unter Reset
geschrieben werden, was ist das denn fürn quark. Hat dein Debugger sowas
wie eine Kommandozeile oder irgendeine API? Ich gehe davon aus, sonst
könnte ja die IDE nicht mit ihm reden. Falls die öffentlich ist kannst
du es darüber versuchen. Bits setzen kann er mit Sicherheit.
Ansonsten mal versuchen, unter reset zu verbinden und dann per Register
view das Bit zu setzen.
:
Bearbeitet durch User
Es geht DOCH! Bei der Suche im Inet bin ich auf den Hinweis gestoßen, das man den Clock für das Debug Register zuerst aktivieren muss. Beim STM32G031 funktioniert folgendes als erste Anweisung im Main: LL_APB1_GRP1_EnableClock(LL_APB1_GRP1_PERIPH_DBGMCU); DBG->APBFZ1 = 0x00001000; (Beispiel Watchdog-Bit setzen) Fazit: traue keinem Manual (von wegen nur der Debugger kann das)
Bernd K. schrieb: >> Designfehler, schlechte Planung. Lieber auf Debugger verzichten und >> stattdessen eine UART nach außen führen. Kein guter Programmierer >> braucht einen Debugger. > > Was für ein Bullshit! "Bullshit?" Du rüpelst wieder mal herum. Der "Haha" hat im Grunde durchaus Recht - und du eben nicht. Mal wieder. Aber so polarisiert sollte man da nicht sehen, sondern es eher so sagen: Wer den Debugger so dringend braucht, daß er ohne ihn nicht auskommt, der ist tatsächlich ein schlechter Entwickler/Programmierer, weil er im Vorfeld gravierende Fehler gemacht hat, als da wären: 1. fehlende oder mangelhafte Modularisierung der Firmware 2. fehlende oder mangelhafte Kapselung von modulinternen Daten 3. schlecht definierte firmwareinterne Schnittstellen 4. für den Anwendungsfall ungeeignete Verwendung von µC-internen Ressourcen. 5. "Kunststückchen" beim Schreiben der Quellcodedateien, anstatt sich simpel und bieder auszudrücken und dem Compiler das Optimieren zu überlassen. 5a. extensives Verwenden von Casts 6. im Schaltungsentwurf nicht an irgendwelche Service-Zugänge gedacht 7. sich auf irgendwelche zugelieferten Programmteile verlassen ohne selbige verstanden und kontrolliert (und zuvor ausgetestet) zu haben So. Wer so beim Entwickeln vorgeht, daß all diese Punkte NICHT zutreffen, der kommt mit 99.9% Wahrscheinlichkeit ohne jeglichen Debugger aus und braucht z.B. ein SWD-Geschirre nur, um den Maschinencode in den Chip zu kriegen. W.S.
Ingo S. schrieb: > Es geht DOCH! > > Bei der Suche im Inet bin ich auf den Hinweis gestoßen, das man den > Clock für das Debug Register zuerst aktivieren muss. > > Beim STM32G031 funktioniert folgendes als erste Anweisung im Main: > > LL_APB1_GRP1_EnableClock(LL_APB1_GRP1_PERIPH_DBGMCU); > DBG->APBFZ1 = 0x00001000; (Beispiel Watchdog-Bit setzen) > > Fazit: traue keinem Manual (von wegen nur der Debugger kann das) Gut zu wissen, danke! Die Frage jetzt ist aber ob es ein Bug ist und es einen Grund hat, dass nur der Debugger unter reset den Pin setzen können soll. Hast du Zeit und Lust das mit ST zu besprechen? :) Wo hast du das gefunden? Aber es ist gut, dass es erstmal geht. Wir wollen die MCU nämlich auch mal evaluieren und wollen möglichst unsere Debug Klassen weiterverwenden. Cool.
Jan K. schrieb: > Die Frage jetzt ist aber ob es ein Bug ist und es einen Grund hat, dass > nur der Debugger unter reset den Pin setzen können soll. Bug oder Missverständnis? Den Text aus dem Reference Manual "nur der Debugger" würde ich anders interpretieren. Die Register verhalten sich genau wie z.B. die GPIO-Register, also muss man den Takt vorher einschalten und dann kann man sie ganz normal benutzen. Der Debugger kann sie natürlich auch lesen und schreiben. Als Bonus kann der Debugger auch unter reset zugreifen, was mit den meisten Registern nicht geht. Deshalb steht das im RM, alles andere ist nicht erwähnenswert, weil normal. Wäre doch denkbar?
:
Bearbeitet durch User
Bauform B. schrieb: > Jan K. schrieb: >> Die Frage jetzt ist aber ob es ein Bug ist und es einen Grund hat, dass >> nur der Debugger unter reset den Pin setzen können soll. > > Bug oder Missverständnis? Den Text aus dem Reference Manual "nur der > Debugger" würde ich anders interpretieren. Die Register verhalten sich > genau wie z.B. die GPIO-Register, also muss man den Takt vorher > einschalten und dann kann man sie ganz normal benutzen. Der Debugger > kann sie natürlich auch lesen und schreiben. > > Als Bonus kann der Debugger auch unter reset zugreifen, was mit den > meisten Registern nicht geht. Deshalb steht das im RM, alles andere > ist nicht erwähnenswert, weil normal. > > Wäre doch denkbar? Beim STM32F103 z.B. ist es so, dass man nicht den Takt aktivieren muss, es gibt genauergesagt gar keinen Takt und daher verhält sich das Register auch nicht wie GPIOs. Wenn man das als GPIO ansieht, wovon ich auf Grund meiner Erfahrung mit derm f103 nicht ausgegangen bin ergibt das Ganze Sinn. Ich hatte aber irgendeine Sicherheits Funktion im Kopf, die ausdrücklich nur erlaubt, die Flag under reset also mit dem Debugger zu setzen. Um irgendwelchen Hacks aus dem Weg zu gehen oder so. Auf die Idee, dass das Register nur mit Debugger geschrieben werden kann ist der Grund, den der OP schon genannt hat, der Satz "it is still possible to write this register by software." Der bei anderen Registern teilweise vorhanden ist fehlt bei ebenjenem :)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.