Ich entwickle schon eine ganze Weile mit SW4STM32 auf dem Nucleo
STM32F722ZE. Seit gestern funktioniert das Debuggen jedoch nicht mehr.
Beim Erreichen eines Breakpoints bricht die Verbindung mit dieser
Fehlermeldung zusammen:
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
Polling target STM32F722ZETx.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 3100ms
...
Ich wüßte nicht, was ich geändert habe, außer vielleicht eine neue
Konfiguration in CubeMX. Mein OpenOCD oder gdb jedenfalls nicht.
Aufgrund der Fehlermeldung würde ich vermuten, daß die Debugging-Session
JTAG und nicht SW mit async Trace verwendet, obwohl das so konfiguriert
ist. Im Code habe ich auch nichts gefunden, was die Pins auf Alternate
setzt oder von JTAG auf SW umschaltet (laut STM32 Referenz).
Im Internet gehen die Vermutungen dahin, daß ST-LINK mit dem Low Power
Modus nicht umgehen kann. Der Einbau von
DBGMCU->CR |= DBGMCU_CR_DBG_SLEEP | DBGMCU_CR_DBG_STOP |
DBGMCU_CR_DBG_STANDBY;
vor oder nach HAL_Init() hat aber auch nichts gebracht.
Hat jemand eine Idee, was diesen Fehler verursachen könnte?
> ohne SWO aktiv ist debuggen nicht so einfach.
Wenn du die SWD Schnittstelle verwendest, ist diese Leitung optional und
wird zur Ausgabe von Debug Meldungen verwendet. Zum Debuggen braucht man
nur SWDIO und SWCLK.
Das war auch nur ein Test. Es hat weder mit SW+Trace noch mit SW alleine
funktioniert.
Laut Referenz startet die Schnittstelle mit JTAG und wird dann auf SW
umgestellt. Weiß jemand, in welcher Funktion das passiert?
Oder was sonst die Ursache ist? (Ich könnte natürlich ein anderes
Nucleo-ST-LINK ausprobieren, aber die Schmerzen ...)
pegel schrieb:> Hast du es schon mit komplett löschen probiert?
Ja, ich habe ein komplett neues Projekt mit CubeMX angelegt, und nur den
Code herüber kopiert (zeilenweise, nicht die ganze Datei).
Hat leider nichts gebracht.
Stefan U. schrieb:> Vielleicht klappt es mit einer geringeren Bitrate
Ich kann mit dem Systemtakt leider nicht viel weiter nach unten gehen
(laufe zur Zeit mit 160 MHz), da sonst mein Projekt nicht mehr
funktioniert.
Uwe B. schrieb:> Verwendest Du WFI/WFE? Hast Du ein "connect under reset" probiert?
Nicht wissentlich. Vielleicht fügt der Compiler das aber automatisch
ein.
Mein Code besteht praktisch nur aus Interrupt-Handlern, die
while-Schleife ist leer. Und die Handler liegen im ITCM-RAM, sofern ich
alles richtig gemacht habe.
Wie macht man Connect Under Reset? Ist das eine Einstellung in OpenOCD
oder gdb?
"Connect Under Reset" ist eine Einstellung des Debuggers, also OpenOCD,
BMP oder des ST Programmers. Bei engen Schleifen, wie "while-Schleife
ist leer" findet der Debugger haeufig keine Moeglichkeit, den
Programmfluss zu unterbrechen. Dagegen hilft "Connect under reset" oder
irgendwelche anderen Befehle in der while Schleife, z.B. Port Wackeln.
IWDG oder WWDG (event. auch hardwaremäßig über option bytes) aktiviert?
Muss man ggf. übers DBGMCU_APB1_FZ stoppen.
Ansonsten habe ich so etwas allerdings beim H7 mit QSPI immer bei
Zugriff auf die letzten 4 Bytes. Daher: FMC oder QSPI in Benutzung?
Und was sagt openOCD, wenn man es mit '-d3' startet? Irgendeine
Fehlermeldung unmittelbar vor dem Verbindungsabbruch?
A. B. schrieb:> IWDG oder WWDG (event. auch hardwaremäßig über option bytes) aktiviert?
Nein, ich denke nicht.
> Ansonsten habe ich so etwas allerdings beim H7 mit QSPI immer bei> Zugriff auf die letzten 4 Bytes. Daher: FMC oder QSPI in Benutzung?
Nee, auch nicht. Wobei ich den FMC mal aktiviert hatte, jetzt aber nicht
mehr.
> Und was sagt openOCD, wenn man es mit '-d3' startet? Irgendeine> Fehlermeldung unmittelbar vor dem Verbindungsabbruch?
Gute Idee, werde ich heute abend mal schauen.
>> Vielleicht klappt es mit einer geringeren Bitrate>Ich kann mit dem Systemtakt leider nicht viel weiter nach unten gehen
Ich meinte die Taktfrequenz der SWJ Schnittstelle.
Der interessante Teil ist vermutlich noch davor. Den "unknown/unexpected
STLINK status code 0x30" kenne ich vom H7, da kam ein Stück davor ein
"SWD_AP_WAIT" oder "SWD_DP_WAIT". Danach half immer nur noch ein
USB-Reset für den STLink.
Dieser Status 0x30 scheint recht neu zu sein. Versionsnummer der
STLink-Firmware?
Das ist ein aktuelles Nucleo-Board, aber laut Tool verwendet es Firmware
V2J28M18, aktuall wäre V2J30M19. Den Update kann ich mal machen.
Inzwischen habe ich herausgefunden, daß BPs nicht generell in Interrupt
Handlers nicht stoppen, sondern nur im gerade interessanten
PendSV-Handler.
PendSV läuft mit Prio 2/0, EXTI mit 0/0 und System-Zeug mit 1/0.
Außerdem verwende ich AXI mit D- und ICache.
lars schrieb:> Das ist ein aktuelles Nucleo-Board, aber laut Tool verwendet es Firmware> V2J28M18, aktuall wäre V2J30M19. Den Update kann ich mal machen.
Besser nicht, ein Downgrade wär' wohl günstiger. Oder ein uralter
STLink.
lars schrieb:> Achso, wegen des interessanten Teils: zwischen den ersten beiden Zeilen> liegt ne ziemliche Zeitspanne ... trotzdem posten?
Nicht komplett, aber wie gesagt, zumindest den Teil mit "WAIT", falls
vorhanden.
A. B. schrieb:> lars schrieb:>> Das ist ein aktuelles Nucleo-Board, aber laut Tool verwendet es Firmware>> V2J28M18, aktuall wäre V2J30M19. Den Update kann ich mal machen.>> Besser nicht, ein Downgrade wär' wohl günstiger. Oder ein uralter> STLink.
Zu spät. :-/ Ist aber genauso wie vorher.
> Nicht komplett, aber wie gesagt, zumindest den Teil mit "WAIT", falls> vorhanden.
Ich habe mal alles angehängt. Der erste BP in main.c hält, der zweite in
PendSV nicht mehr. Dazwischen liegen so ungefähr 2 Sekunden.
Noch was Komisches:
Wenn ich in CubeMX mit der Maus auf der Auswahl der Debug-Schnittstelle
zeige (also da, wo jetzt Debug: Trace Asynchronous Sw steht) erscheit
ein Popup mit dem Hinweis:
Conflict with PG13 mapped to GPIO_Input or/and
PE2 mapped with GPIO_EXTI2 or/and
PB4 mapped with GPIO_Input
Aber was haben PG13, PE2 und PB4 mit SWD zu tun?
Machst Du Deine Debug-Tests eigentlich mit Deinem aktuellen
Firmwarestand, oder einem alten Minimal-Stand, mit dem Debug mit
Sicherheit schon funktioniert hat?
Im Log steht leider auch nichts sonderlich Brauchbares. Außer, dass
mehrere Breakpoints gesetzt werden. Daher: Passiert das auch, wenn nur
der eine interessante gesetzt wird (in der gesamten Session!)? Der f722
erlaubt ja bis zu 8, openOCD zeigt das auch so an, aber vielleicht ist
in der Verwaltung der Breakpoints irgendwas durcheinander ...
Walter T. schrieb:> Machst Du Deine Debug-Tests eigentlich mit Deinem aktuellen> Firmwarestand, oder einem alten Minimal-Stand, mit dem Debug mit> Sicherheit schon funktioniert hat?
Ich benutzte den oben irgendwo genannten Stand, mit dem erst alles
funktionierte, und dann plötzlich BP in bestimmten Abschnitten nicht
mehr hielten.
Danach habe ich erst das Update gemacht, was aber nicht geholfen hat.
A. B. schrieb:> Passiert das auch, wenn nur der eine interessante gesetzt wird (in der> gesamten Session!)?
Leider ja, die Anzahl der BP scheint keine Rolle zu spielen.
STM32Cube hat eine etwas eigenwillige Art und Weise die Konfiguration
der Mapping-Register vorzunehmen (Read-Modify-Write auf Write-Only
Registern).
Auf meinem F103 hat es geholfen nach dem ganzen Init nocheinmal
"manuell" per " __HAL_AFIO_REMAP_SWJ_NOJTAG();" den SWD zu aktivieren.
Ich habe mir nochmal eine alte Version meines Projektes angeschaut, wo
die BP noch funktioniert haben. Leider muß ich zum Testen noch die
Verkabelung ändern.
Aber in CubeMX ist mir schon aufgefallen, daß die SYS->Debug Einstellung
keine Warnung enthält, obwohl ebenfalls Trace Async SW eingestellt ist.
Dazu nochmal meine Frage: Wieso sieht CubeMx im aktuellen Projekt einen
Konflikt "PG13 mapped to GPIO_Input or/and PE2 mapped with GPIO_EXTI2
or/and PB4 mapped with GPIO_Input"? Die verwendeten Pins sind doch PA13,
PA14 und PB3. Die Antwort von Uwe habe ich nicht verstanden.
Nur der Vollständigkeit halber:
Ich bin auf eine alte Version von SW4STM32 (und damit auch OpenOCD)
gewechselt, was aber nicht geholfen hat.
Dann habe ich eine ältere Version meines Projektes getestet, und dort
funktionieren die BP einwandfrei.
Ich muß also prüfen, was zwischenzeitlich von mir geändert wurde.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang