Forum: Mikrocontroller und Digitale Elektronik STM32 Nucleo Debuggen funktioniert nicht mehr


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hänge doch mal deine ioc Datei an.

von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Gerne!

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dein SYS -> Debug steht auf "Serial Wire",
nicht auf "Trace Asynchronous Sw".

Könnte das das Problem sein?

von dasrotemopped (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>>Hänge doch mal deine ioc Datei an.
>Gerne!

ohne SWO aktiv ist debuggen nicht so einfach.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ...)

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hast du es schon mit komplett löschen probiert?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Vielleicht klappt es mit einer geringeren Bitrate

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
0 lesenswert
nicht lesenswert
Verwendest Du WFI/WFE? Hast Du ein "connect under reset" probiert?

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
0 lesenswert
nicht lesenswert
"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.

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
>> 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.

von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Achso, wegen des interessanten Teils: zwischen den ersten beiden Zeilen 
liegt ne ziemliche Zeitspanne ... trotzdem posten?

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von lars (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
0 lesenswert
nicht lesenswert
Trace?

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Uwe B. schrieb:
> Trace?

Trace ist PB3?

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
Machst Du Deine Debug-Tests eigentlich mit Deinem aktuellen 
Firmwarestand, oder einem alten Minimal-Stand, mit dem Debug mit 
Sicherheit schon funktioniert hat?

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ...

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Max D. (max_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
0 lesenswert
nicht lesenswert
lars schrieb:
> Trace ist PB3?

PB3(JTDO/TRACESWO)

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von lars (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.