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?
Dein SYS -> Debug steht auf "Serial Wire", nicht auf "Trace Asynchronous Sw". Könnte das das Problem sein?
>>Hänge doch mal deine ioc Datei an. >Gerne! ohne SWO aktiv ist debuggen nicht so einfach.
> 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 ...)
Verwendest Du WFI/WFE? Hast Du ein "connect under reset" probiert?
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.
Angehängte Dateien:
-
debug-config.png
91 KB
Anbei ist erstmal meine Debug-Konfiguration, sieht normal aus. Und eine interessante Beobachtung habe ich gemacht. Wenn ich einen Breakpoint auf eine einfache Funktion setze, welche von main.c aufgerufen wird, dann funktioniert der BP ganz normal! Nur BP auf meinen Interrupt-Handlern ergeben den o.g. Fehler?! Hier ist die Ausgabe von OpenOCD mit -d3 (ich denke, ich habe den kritischen Abschnitt erwischt): ... Debug: 3138 9408 target.c:1522 target_call_event_callbacks(): target event 4 (resume-end) Debug: 3139 20965 stlink_usb.c:530 stlink_usb_error_check(): SWD_AP_ERROR Error: 3140 20965 hla_target.c:446 adapter_poll(): jtag status contains invalid mode value - communication failure Debug: 3141 20965 target.c:1522 target_call_event_callbacks(): target event 0 (gdb-halt) Warn : 3142 20965 target.c:1180 target_get_gdb_fileio_info(): target STM32F722ZETx.cpu is not halted User : 3143 20965 target.c:2696 handle_target(): Polling target STM32F722ZETx.cpu failed, trying to reexamine Debug: 3144 20965 target.c:1522 target_call_event_callbacks(): target event 21 (examine-start) Debug: 3145 20965 hla_target.c:751 adapter_read_memory(): adapter_read_memory 0xe000ed00 4 1 Debug: 3146 20966 stlink_usb.c:530 stlink_usb_error_check(): SWD_AP_ERROR Debug: 3147 20966 target.c:2266 target_read_u32(): address: 0xe000ed00 failed User : 3148 20966 target.c:2704 handle_target(): Examination failed, GDB will be halted. Polling again in 100ms Debug: 3149 20966 gdb_server.c:2812 gdb_input_inner(): received packet: 'g' Debug: 3150 20966 gdb_server.c:2812 gdb_input_inner(): received packet: 'm800579c,4' Debug: 3151 20966 gdb_server.c:1386 gdb_read_memory_packet(): addr: 0x000000000800579c, len: 0x00000004 Debug: 3152 20966 target.c:2113 target_read_buffer(): reading buffer of 4 byte at 0x0800579c Debug: 3153 20966 hla_target.c:751 adapter_read_memory(): adapter_read_memory 0x0800579c 4 1 Debug: 3154 20968 stlink_usb.c:530 stlink_usb_error_check(): SWD_AP_ERROR Debug: 3155 20968 gdb_server.c:2812 gdb_input_inner(): received packet: 'qXfer:threads:read::0,fff' Debug: 3156 20969 gdb_server.c:2812 gdb_input_inner(): received packet: 'z1,8004726,2' Debug: 3157 20969 gdb_server.c:1585 gdb_breakpoint_watchpoint_packet(): - Warn : 3158 20969 cortex_m.c:1304 cortex_m_remove_breakpoint(): target not halted Debug: 3159 20969 breakpoints.c:307 breakpoint_free(): free BPID: 2 --> -304 Debug: 3160 20999 gdb_server.c:2812 gdb_input_inner(): received packet: 'qXfer:threads:read::0,fff' Debug: 3161 20999 gdb_server.c:2812 gdb_input_inner(): received packet: 'qXfer:threads:read::0,fff' Info : 3162 21199 stlink_usb.c:1169 stlink_usb_state(): Previous state query failed, trying to reconnect Debug: 3163 21200 stlink_usb.c:506 stlink_usb_error_check(): JTAG_GET_IDCODE_ERROR Error: 3164 21200 hla_target.c:446 adapter_poll(): jtag status contains invalid mode value - communication failure Debug: 3165 21200 target.c:1522 target_call_event_callbacks(): target event 0 (gdb-halt) User : 3166 21200 target.c:2696 handle_target(): Polling target STM32F722ZETx.cpu failed, trying to reexamine Debug: 3167 21200 target.c:1522 target_call_event_callbacks(): target event 21 (examine-start) Debug: 3168 21200 hla_target.c:751 adapter_read_memory(): adapter_read_memory 0xe000ed00 4 1 Debug: 3169 21201 stlink_usb.c:566 stlink_usb_error_check(): unknown/unexpected STLINK status code 0x30 Debug: 3170 21201 target.c:2266 target_read_u32(): address: 0xe000ed00 failed User : 3171 21201 target.c:2704 handle_target(): Examination failed, GDB will be halted. Polling again in 300ms Info : 3172 21601 stlink_usb.c:1169 stlink_usb_state(): Previous state query failed, trying to reconnect Debug: 3173 21602 stlink_usb.c:506 stlink_usb_error_check(): JTAG_GET_IDCODE_ERROR Error: 3174 21602 hla_target.c:446 adapter_poll(): jtag status contains invalid mode value - communication failure Debug: 3175 21602 target.c:1522 target_call_event_callbacks(): target event 0 (gdb-halt) User : 3176 21602 target.c:2696 handle_target(): Polling target STM32F722ZETx.cpu failed, trying to reexamine Debug: 3177 21602 target.c:1522 target_call_event_callbacks(): target event 21 (examine-start) Debug: 3178 21602 hla_target.c:751 adapter_read_memory(): adapter_read_memory 0xe000ed00 4 1 Debug: 3179 21603 stlink_usb.c:566 stlink_usb_error_check(): unknown/unexpected STLINK status code 0x30 Debug: 3180 21603 target.c:2266 target_read_u32(): address: 0xe000ed00 failed User : 3181 21603 target.c:2704 handle_target(): Examination failed, GDB will be halted. Polling again in 700ms Info : 3182 22404 stlink_usb.c:1169 stlink_usb_state(): Previous state query failed, trying to reconnect Debug: 3183 22405 stlink_usb.c:506 stlink_usb_error_check(): JTAG_GET_IDCODE_ERROR Error: 3184 22405 hla_target.c:446 adapter_poll(): jtag status contains invalid mode value - communication failure Debug: 3185 22405 target.c:1522 target_call_event_callbacks(): target event 0 (gdb-halt) User : 3186 22405 target.c:2696 handle_target(): Polling target STM32F722ZETx.cpu failed, trying to reexamine Debug: 3187 22405 target.c:1522 target_call_event_callbacks(): target event 21 (examine-start) Debug: 3188 22405 hla_target.c:751 adapter_read_memory(): adapter_read_memory 0xe000ed00 4 1 Debug: 3189 22405 stlink_usb.c:566 stlink_usb_error_check(): unknown/unexpected STLINK status code 0x30 Debug: 3190 22405 target.c:2266 target_read_u32(): address: 0xe000ed00 failed User : 3191 22405 target.c:2704 handle_target(): Examination failed, GDB will be halted. Polling again in 1500ms ... So richtig sagt mit das aber nichts. ST Link USB Error?
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.
Achso, wegen des interessanten Teils: zwischen den ersten beiden Zeilen liegt ne ziemliche Zeitspanne ... trotzdem posten?
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.
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.