Hallo,
mein Projekt benutzt einen STM32F7 auf einer eigenen Platine. Bisher
habe ich ein Nucleo mit ST-Link und SWD benutzt, aber mit dem Umzug auf
meine eigene Platine funktioniert das Anhalten an Breakpoints nicht
mehr.
Daraufhin bin ich zu Atollic Studio und J-Link gewechselt, aber das
Problem tritt auch dort auf: Flashen funktioniert, aber beim Debuggen
wird bei Erreichen eines Breakpunktes nur eine Fehlermeldung ausgegeben:
1
...
2
ERROR: Can not read register 43 (FPS10) while CPU is running
3
ERROR: Can not read register 44 (FPS11) while CPU is running
4
ERROR: Can not read register 45 (FPS12) while CPU is running
5
ERROR: Can not read register 46 (FPS13) while CPU is running
6
ERROR: Can not read register 47 (FPS14) while CPU is running
7
ERROR: Can not read register 48 (FPS15) while CPU is running
8
ERROR: Can not read register 49 (FPS16) while CPU is running
9
...
Ich benutze ein originales J-Link EDU. Mein Debug-Skript (generiert)
sieht so aus:
1
# Default GDB command file (FLASH) for SEGGER J-LINK and STMicroelectronics STM32F722ZC microcontroller.
2
# Set character encoding
3
set host-charset CP1252
4
set target-charset CP1252
5
# Set JTAG speed to 30 kHz
6
monitor speed 30
7
# Set GDBServer to little endian
8
monitor endian little
9
# Reset the chip to get to a known state.
10
monitor reset
11
# Set auto JTAG speed
12
monitor speed auto
13
# Setup GDB FOR FASTER DOWNLOADS
14
set remote memory-write-packet-size 1024
15
set remote memory-write-packet-size fixed
16
# Enable flash download
17
monitor flash download = 1
18
# Load the program executable
19
load
20
# Reset the chip to get to a known state. Remove "monitor reset" command
21
# if the code is not located at default address and does not run by reset.
22
monitor reset
23
# Set a breakpoint at main().
24
tbreak main
25
# Run to the breakpoint.
26
continue
Ich benutze SWD mit zwei Leitungen, ohne Tracing. Der Konnektor
entspricht den ST-Links auf Nucleo-Boards, also Vtref, SWDIO, SWCLK,
NRST, GND.
Ist das ein generelles Problem mit meiner Platine oder nur ein
Konfigurationsproblem?
Neverever schrieb:> SWDIO hat zwar einen internen Pullup, aber Segger empfiehlt trotzdem> einen externen. Hast Du den dran?
Nein, dass kann ich gleich ausprobieren. Wobei das Flashen und das
geflashte Programm ja problemlos funktionieren.
> Schaltplan fehlt!
Ja, hier ist der Anschluß für SWD. Die Leitungen gehen direkt zur MCU.
Habe es mit und ohne dem eingezeichneten Pull-up an RESET ausprobiert.
Noch ein Hinweis: Der automatisch generierte Breakpoint in main()
funktioniert, nur die von mir gesetzten nicht.
Der Pullup bewirkt leider gar nichts.
Noch eine Beobachtung: Wenn ich weitere Breakpunkte in main() oder
direkt aufgerufenen Funktionen setze, funktionieren diese wie gewohnt.
Nur wenn ich Breakpunkte in von EXTI Interrupts ausgelösten Funktionen
setze, kommt es zu oben geschildertem Fehler.
Daher nochmal meine Frage: Kann es an den Einstellungen zu IRs und deren
Prios liegen? Meine Konfiguration ist anbei.
Hallo,
ggf ist der debugmode der CPU von swd auf jtag umgestellt worden. (je
nach CPU verwendet JTAG die gleichen pins wie SWD)
Die kleinen STM32 haben da ein paar register die das steuern. ggf die
grossen auch.
Flashen geht, ... debuggen im startup Code auch bis zu ner bestimmten
stelle dann ist ende. kann man ggf in den codegeneratoren von ST
einstellen.
gruss
123 schrieb:> ggf ist der debugmode der CPU von swd auf jtag umgestellt worden. [...]> kann man ggf in den codegeneratoren von ST> einstellen.
Das klingt zwar sehr zielführend, aber ich habe ein solches Register
nicht in der Referenz finden können. Wo soll man das umstellen können -
im Compiler?!
Hab grad mal den 1400 seiten Schmöker angelsen.
Es gibt anscheinend keine register die das steuern. beim F7 wird das
über eine startup sequenz gemacht. Kapitel 34.3 SWJ debug port und
folgend.
ggf pfuscht ein nReset da mit rein. und setzt etwas bei der erkennung
zurück?
Prüf auch noch mal die Pin configuration für PA13 und PA14. da digbt es
noch was mit eventout als alternativ function für die Pins. ggf wird
umkonfiguriert und dann ist der SWD tot.
gruss
Lutz schrieb:> Welche Hardware Version hat der j-link? Muss mindestens V9 sein.
SEGGER J-Link Commander V6.34a (Compiled Aug 8 2018 16:31:54)
DLL version V6.34a, compiled Aug 8 2018 16:31:24
Connecting to J-Link via USB...O.K.
Firmware: J-Link V10 compiled Jul 23 2018 09:53:14
Hardware version: V10.10
123 schrieb:> Es gibt anscheinend keine register die das steuern. beim F7 wird das> über eine startup sequenz gemacht. Kapitel 34.3 SWJ debug port und> folgend.
Ja, das habe ich auch gelesen.
> Prüf auch noch mal die Pin configuration für PA13 und PA14. da digbt es> noch was mit eventout als alternativ function für die Pins. ggf wird> umkonfiguriert und dann ist der SWD tot.
OK, aber was soll ich da überprüfen? Die werden beide als SYSxxx
konfiguriert und nicht wieder geändert.
Ganz doof gefragt: Sind Deine Timer richtig konfiguiert? Dieses Problem
hatte ich auch mal mit einem STM32F4 und Keil mit einem original
STLink/V2 und den Umstieg vom Nucleo auf eigener PCB. Bei mir war das
der externe Quarz.
Gruß
Daniel
Daniel V. schrieb:> Ganz doof gefragt: Sind Deine Timer richtig konfiguiert? Dieses Problem> hatte ich auch mal mit einem STM32F4 und Keil mit einem original> STLink/V2 und den Umstieg vom Nucleo auf eigener PCB. Bei mir war das> der externe Quarz.
Was ist denn "richtig"? :-) Und welche Timer genau? Ich verwende nur
SysTick, dessen IR eine niedrigere Prio hat als der IR meiner Funktion,
die debuggen will und nicht kann.
Um die Fehlersuche etwas einzugrenzen nochmal etwas zum Kontext.
Diesen Hält-nicht-an-manchen-Breakpoints hatte ich schon einmal, und
zwar auf einem Nucleo-Board mit ST-Link. Auch damals habe ich den Fehler
nicht gefunden, sondern bin auf eine ältere Version meines Codes
zurückgegangen, wo dieser Fehler noch nicht auftrat. Beim
Weiterentwickeln der alten Version trat das Problem nicht mehr auf, bis
jetzt.
Es wäre ein komischer Zufall, wenn es jetzt an J-Link liegen würde, oder
meinem Board.
Leider kann ich diesmal auf keine ältere Version zurückgreifen, da dies
die erste Version für das Board ist.
Hi,
vielleicht eine doofe frage, der Jlink ist original?
Sehr ähnliche Probleme hatte/habe ich mit einem Clone weshalb dieser in
die Tonne wandert.
Nucleoboard mit Jlink-Firmeware läuft tadellos.
Hallo
SYS ist OK aber AF0 oder AF15? AF0 ist OK AF15 nicht.
Segger und Cortex können nur eine begrenzte anzahl an breakpoints.
werden mehr eingestellt, läuft der einfach drüber. die CDT meckert dann.
Kannst du deinen code überhaupt debuggen? ggf mal versuchen stück für
stück durch den code zu gehen und rauszubekommen wo die kiste
wegschmiert. wenn es reproduzierbar ist. aber dabei aufpassen das du nur
eine begrenzte anzahl an breakpoints hast.
- treten irgendwelche exceptions auf die einen reset auslösen.
- watch dog ist hoffentlich nicht scharfgeschalten ( böse beim debuggen)
- pin reconfiguration siehe oben
- clock umstellungen die daneben gehen
- Pll configurationen die nicht funktioniert hat
Funktioniert auch der halt aus der IDE nicht?
123 schrieb:> Hallo
Herzlichen Dank für Deine Ideen! Ich habe dabei etwas ganz grundlegendes
herausgefunden.
Der oben beschriebe Fehler tritt nicht bei Erreichen eines Breakpoints
auf, sondern einfach bei Erreichen einer gewissen, unbekannten Stelle!
Im TrueStudio wird kein BP angezeigt, ich habe den STM32 mit dem J-Link
Commander komplett "erased" und neu geflasht. Ich denke also, daß keine
BP mehr gesetzt sein dürften - trotzdem der Fehler.
Das macht die Sache für mich aber noch misteriöser ...
Wenn ich das Programm nicht im Debug-Modus ausführe, hängt mein Programm
an vermutlich der gleichen Stelle, weswegen ich ja debuggen wollte.
> Kannst du deinen code überhaupt debuggen? ggf mal versuchen stück für> stück durch den code zu gehen und rauszubekommen wo die kiste> wegschmiert.
Im Debug-Modus bin ich vom BP in main.c mal weitergesteppt. Mein Code
sieht so aus:
1
intmain(void)
2
{
3
SCB_EnableICache();
4
SCB_EnableDCache();
5
HAL_Init();
Ich bin in SCB_EnableDCache hängen geblieben, ohne Fehlermeldung, aber
mein grüner Balken im Code war einfach weg. Debug-Modus war an, aber
Single Step oder ||-Knopf funktionierte nicht.
Aber die eigentlich Frage ist: Wie kann Code einen Debugger so aus dem
Konzept bringen, daß er sich aufhängt? Was sollte ich im Debugger
vielleicht deaktivieren? (So viele Optionen hat Atollic da nicht.)
Lars schrieb:> Aber die eigentlich Frage ist: Wie kann Code einen Debugger so aus dem> Konzept bringen, daß er sich aufhängt?
Frage mal die Optimierungs-Stufen deines Projekts für den Compiler.
Wegg-optimierte Code-Zeilen können schlecht "ge-breakt" werden.
(wegg vs Weg)
Opti Mator schrieb:> Frage mal die Optimierungs-Stufen deines Projekts für den Compiler.>> Wegg-optimierte Code-Zeilen können schlecht "ge-breakt" werden.> (wegg vs Weg)
Bringt nix. War -Os für Compiler und -g für Debugger.
Habe jetzt auch -Og und -g3 ausprobiert, kein Erfolg.
123 schrieb:> Prüf auch noch mal die Pin configuration für PA13 und PA14. da digbt es> noch was mit eventout als alternativ function für die Pins. ggf wird> umkonfiguriert und dann ist der SWD tot.
*ARRRGHH!* Ich bin so dumm, und ihr so clever!
Natürlich steht in meinem Code ganz verschämt
1
GPIOA->ODR=data;
2
GPIOA->MODER=DATA_MODER;
und irgendwo anders
1
#define DATA_MODER 0x00005555
was die SWD-Pins plattmacht. m)
Fall gelöst! Herzlichen Dank an alle, die die Geduld mit mir nicht
verloren haben. :-)
Lars schrieb:> Fall gelöst! Herzlichen Dank an alle, die die Geduld mit mir nicht> verloren haben. :-)
Du wolltest ja nur dass wir in diesem Sommerloch nicht gänzlich
geistig dahinsiechen.
Lars schrieb:> *ARRRGHH!*
Danke für die Aufklärung, man hätte die Nachwelt ja auch dumm sterben
lassen können.
Da der Breakpoint beim main() noch funktionierte hätte man sich doch
auch an die Stelle vorarbeiten können an der der Debugger sich abklemmt?
Bei einigen µC sägt man sich auch bei einigen deep sleep Modi ab, das
könnte vielleicht auch mal ausgelöst werden ohne das man damit rechnet.
Johannes S. schrieb:> Da der Breakpoint beim main() noch funktionierte hätte man sich doch> auch an die Stelle vorarbeiten können an der der Debugger sich abklemmt?
Schwierig, da außer der Initialisierung alles Interrupt-getrieben ist,
und das Debuggen schon nach dem ersten Interrupt kaputt ist.
Thread beobachten
Seitenaufteilung abschalten