Immer noch Problem mit dem DIY-MORE Target. Programmierung der Anwendung des STM32F407G-DISC1 auf der On-Board MCU aus STM32CUBEIDE funktioniert. Sobald ich auf das über SWD angeschlossene externe DIY-MORE Board wechsle, gibt's die Probleme. GDB Server kann nicht mit dem Target verbinden. Einerseits wurde behauptet, es läge daran, daß das Target eine gefälschte MCU sei (Clone), andererseits kann ich es nicht so richtig glauben. Deshalb noch eine Frage zur Verdrahtung: Ich habe drei Drähte von der SWD Stiftleiste zum Target gehen: SWCLK - 2 SWDIO - 4 NRST - 5 Dann gehen noch GND und Vcc von den Stiftleisten des Targets zu GND und +5V (an P2). Sollte ich stattdessen GND (3) und "Vdd from application" (1) mit 3.3V des Targets verbinden und 5V weglassen?
Christoph K. schrieb: > Ich habe drei Drähte von der SWD Stiftleiste zum Target gehen: > SWCLK - 2 > SWDIO - 4 > NRST - 5 Auf NRST kann man fast immer verzichten - auf GND niemals.
Gast
#7019428
Christoph K. schrieb: > Sobald ich auf das über SWD angeschlossene externe DIY-MORE Board > wechsle, > gibt's die Probleme. GDB Server kann nicht mit dem Target verbinden. Es ist immer ungemein hilfreich, die wichtigen Informationen auszulassen. Spionagegefahr!!! An WAS ist das Board angeschlossen bzw. an WAS soll es angeschlossen werden??? > Ich habe drei Drähte von der SWD Stiftleiste zum Target gehen: > SWCLK - 2 > SWDIO - 4 > NRST - 5 > > Dann gehen noch GND und Vcc von den Stiftleisten des Targets > zu GND und +5V (an P2). Von WAS ??? > Sollte ich stattdessen GND (3) und "Vdd from application" (1) mit 3.3V > des Targets verbinden und 5V weglassen? (1) und (3) von WAS???
War aus meiner Problemschilderung nicht zu entnehmen, daß es sich um den SWD Anschluß des Discoveryboards handelt? Womit dann auch die Pinnummern und Pfosten (P2) klar sein dürften. Ebenso habe ich das Target genannt. Was fehlt da an Informationen?
Neue Erkenntnis:
1 | |
2 | |
3 | |
4 | |
5 | |
Kann ich das irgendwie umgehen? Blackmagic?
Gast
#7020078
Ich habe mal eine gefälschte MCU aus China erwischt. OpenOCD ist dies wohl egal. Unter Projekteigenschaften kann man in der STMCubeIDE von ST-Link-GDB-Server auf OpenOCD wechseln (Run/Debug Settings->Edit Configuration -> Debugger -> Debug Probe)
Christoph K. schrieb: > chip id! 0x374b wäre ein Fälscher so blöd, eine unmögliche chip id einzubauen? Hatten wir schon: SWD-Taktfrequenz zu hoch für dieses Target?
Oder auf dem Discovery den Debugger nicht von der internen MCU getrennt....
Harry L. schrieb: > Oder auf dem Discovery den Debugger nicht von der internen MCU > getrennt.... Nein, nicht der Fall. Schrieb ich eingangs, daß es um das extern angeschlossene Traget geht.
Bauform B. schrieb: > Christoph K. schrieb: >> chip id! 0x374b > > wäre ein Fälscher so blöd, eine unmögliche chip id einzubauen? > Hatten wir schon: SWD-Taktfrequenz zu hoch für dieses Target? Wo soll ich denn im CMD-line st-flash eine Clock einstellen?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
Mal eine Frage zum st-flash utility: Wenn das meldet, daß eine ungültige MCU (gefälschte) angeschlossen sei, und früher war das nicht so, liegt das dann an der Version der ST-LINK Firmware? Doch wohl eher nicht am st-flash utility selbst? Kann man eine ältere Version ins ST-LINK Interface (des DISCOVERY-Boards) flashen? Und noch was: OpenOCD benutzt doch auch die ST-LINK Firmware, oder? Mit OpenOCD kriege ich ja auch keinen stabilen Zustand hergestellt.
Gast
#7021142
Christoph K. schrieb: > Und noch was: OpenOCD benutzt doch auch die ST-LINK Firmware, oder? Mit > OpenOCD kriege ich ja auch keinen stabilen Zustand hergestellt. Wie schon mal: was "kein stabiler Zustand" ist, scheint ein großes Geheimnis zu sein, oder??? Ist es eigentlich so schwierig, sich in die Lage eines Leser zu versetzen, der nur genau das wissen kann, was hier an Beschreibung gegeben wird? Wir (zumindest ich) sitzen (bis auf einen) nicht davor und sehen bzw. wissen nicht, was wo passiert/ausprobiert wurde, sondern sind auf eine präzise und vollständige Beschreibung der Gesamtumstände angewiesen.
Hardware-Aufbau: macOS BigSur 11.6.4 MacBookPro An USB hängt das STM32F407G-DISC1 board. CN3 Jumper Off (also on board MCU) abgeklemmt. DIY-MORE Board wird über Vcc und GND vom DISCOVERY P2 Leiste Vcc GND versorgt. SWCLK und SWDIO vom SWD-Interface des DISCOVERY gehen an PA14/PA13 des DIY-MORE Board. Software: st-flash erase ergibt oben gepostete Ausgabe:
1 | |
2 | |
3 | |
4 | |
5 | |
Starte ich OpenOCD in einem Terminalfenster, so steigt OpenOCD aus:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
Erst mal soweit. Warum steigt OpenOCD aus?
Angehängte Dateien:
-
IMG_2719.jpg
(220 KB)
Christoph K. schrieb: > Wenn das meldet, daß eine ungültige MCU (gefälschte) angeschlossen sei, > und früher war das nicht so, liegt das dann an der Version der ST-LINK > Firmware? Doch wohl eher nicht am st-flash utility selbst? ob die gefälscht ist wäre ja noch zu klären. Ich würde als Hersteller (ST) auch nur meine eigenen IDs unterstützen. Es ist ja z.B nicht sichergestellt dass andere Hersteller die gleichen Flash Operationen haben. Wenn das so ist hat dein Hersteller sicher auch passende Flashsoftware. PS google fördert das zu tage inc Lösungen. https://github.com/stlink-org/stlink/issues/1012
Thomas Z. schrieb: > Christoph K. schrieb: >> Wenn das meldet, daß eine ungültige MCU (gefälschte) angeschlossen sei, >> und früher war das nicht so, liegt das dann an der Version der ST-LINK >> Firmware? Doch wohl eher nicht am st-flash utility selbst? > > ob die gefälscht ist wäre ja noch zu klären. Ich würde als Hersteller > (ST) auch nur meine eigenen IDs unterstützen. Es ist ja z.B nicht > sichergestellt dass andere Hersteller die gleichen Flash Operationen > haben. Wenn das so ist hat dein Hersteller sicher auch passende > Flashsoftware. Nun wurde mir hier aber gesagt, ich solle es mal mit OpenOCD versuchen. Aber OpenOCD benutzt doch sicher auch die im Discovery-Board gespeicherte ST-LINK Firmware Version, oder? Meine Frage unter anderem wäre die: kann ich auf eine frühere ST-LINK Firmware zurück? Habe jetzt kein frisches Original Discoveryboard mehr. Die drei, die ich habe, sind alle mit der neuesten ST-LINK Firmware geflasht.
wie oben geschrieben google "Chip id 0x374b" bringt einiges zutage. Du bist nicht der einzige.
und noch was: Im ganzen Thread habe ich nirgens gelesen welche Target CPU du denn eigentlich hast. Ich lese da nur von DIY MORE was ist das?
Thomas Z. schrieb: > und noch was: > Im ganzen Thread habe ich nirgens gelesen welche Target CPU du denn > eigentlich hast. Ich lese da nur von DIY MORE was ist das? https://stm32-base.org/boards/STM32F407VGT6-diymore.html
Thomas Z. schrieb: ... > > PS google fördert das zu tage inc Lösungen. > > https://github.com/stlink-org/stlink/issues/1012 Die vermeintlichen Lösungen funktionieren bis jetzt bei mir nicht.
Gast
#7021400
Christoph K. schrieb: > Starte ich OpenOCD in einem Terminalfenster, so steigt OpenOCD aus: > >
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
> > Erst mal soweit. > Warum steigt OpenOCD aus? Dass es das tut, sehe ich nicht. Das sieht erst mal so aus, dass es weiter nichts macht: Das "Listening ..." heißt doch, "ich warte auf Anweisungen". Da könnte ma ja mal mit telnet auf den Port los und mal ein paar interaktive Kommandos versuchen. "reset init" oder "flash probe 0" wären Kandidaten dafür. Wo ist denn die Angabe der cfg-Datei für OpenOCD, und was steht da drin. Vielleicht versteckt sich das irgendwo hinter dem ominösen "./DEBUG", das ist doch vmtl. ein Script mit (mir jedenfalls) unbekanntem Inhalt. Um mehr Info zu bekommen, emphiehlt sich zusätzlich der Parameter "-d 3".
A. B. schrieb: > Christoph K. schrieb: >> Starte ich OpenOCD in einem Terminalfenster, so steigt OpenOCD aus: >> >>
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
>> >> Erst mal soweit. >> Warum steigt OpenOCD aus? > > Dass es das tut, sehe ich nicht. Das sieht erst mal so aus, dass es > weiter nichts macht: Das "Listening ..." heißt doch, "ich warte auf > Anweisungen". Ich hätte noch den $ Prompt hinzufügen sollen. Wenn ich sage, es steigt aus, sollte das eigentlich genügen. Es dauert ca. 10 Sek., dann kommt der Prozeß zurück auf den Prompt. > Da könnte ma ja mal mit telnet auf den Port los und mal ein paar > interaktive Kommandos versuchen. "reset init" oder "flash probe 0" wären > Kandidaten dafür. > Wie gesagt, der Prozeß macht kein "Listen", sondern steigt aus. Üblicherweise steht bei einem funktionierndem Server noch etwas mehr, bis er in das Listen geht. > Wo ist denn die Angabe der cfg-Datei für OpenOCD, und was steht da drin. > Vielleicht versteckt sich das irgendwo hinter dem ominösen "./DEBUG", > das ist doch vmtl. ein Script mit (mir jedenfalls) unbekanntem Inhalt. > Um mehr Info zu bekommen, emphiehlt sich zusätzlich der Parameter "-d > 3". Mein DEBUG-Script (dem man schon einige Versuche mit anderen Versionen und boards entnehmen kann):
1 | |
2 | |
3 | |
4 | |
5 | |
Gast
#7021433
Christoph K. schrieb: > Ich hätte noch den $ Prompt hinzufügen sollen. Wenn ich sage, es steigt > aus, sollte das eigentlich genügen. > Es dauert ca. 10 Sek., dann kommt der Prozeß zurück auf den Prompt. Aha, das weiß man natürlich beim Blick in die Glaskugel ... Allein "10s" sind schon aufschlußreich, denn bei einem Verbindungsproblem gleich zu Beginn sollte das schon nach 1 bis 2s passieren. Wie wär's denn dann mal mit .../openocd -f.../stm32f4discovery.cfg -d3
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
122 | |
123 | |
124 | |
125 | |
126 | |
127 | |
128 | |
129 | |
130 | |
131 | |
132 | |
133 | |
134 | |
135 | |
136 | |
137 | |
138 | |
139 | |
140 | |
141 | |
142 | |
143 | |
144 | |
145 | |
146 | |
147 | |
148 | |
149 | |
150 | |
151 | |
152 | |
153 | |
154 | |
155 | |
156 | |
157 | |
158 | |
159 | |
160 | |
161 | |
162 | |
163 | |
164 | |
165 | |
166 | |
167 | |
168 | |
169 | |
170 | |
171 | |
Gast
#7021441
Christoph K. schrieb: > Debug: 136 5 stlink_usb.c:3709 stlink_open(): transport: 4 vid: 0x0483 > pid: 0x3754 serial: > Debug: 137 7045 stlink_usb.c:3385 stlink_usb_usb_open(): claim interface > failed > Debug: 138 7045 stlink_usb.c:693 jtag_libusb_bulk_transfer_n(): ERROR, > failed to submit transfer 0, error -5 > Debug: 139 7047 hla_layout.c:47 hl_layout_open(): failed > Debug: 140 7047 command.c:555 run_command(): Command 'transport init' > failed with error code -4 > User : 141 7047 command.c:619 command_run_line(): > Debug: 142 7047 command.c:555 run_command(): Command 'init' failed with > error code -4 Hat also gar nichts mit dem Target zu tun, sondern mit dem USB-Interface. Eventuell Zugriffsrechte fürs USB Device oder irgendjemand sonst wurschtelt an dem Device rum? Vielleicht noch eine alte Instanz von OpenOCD oder st-flash? Über lsusb (gibt's das aufm Mac?) sollte man das USB Device ermitteln können, so etwas wie /dev/usb/.../..., dann kann man mittels 'ls' und 'fuser' nachsehen, was da los ist.
Gast
#7021476
Versorgst du etwa beide Board über das USB Kabel? Dann hast du da vielleicht den Schwachpunkt. Ich habe inzwischen eine ganze Reihe von Kabeln, die nicht einmal mehr für ein Nucleo Board (ohne weitere Last) taugen. Wenn du den USB Port einmal kurzgeschlossen hattest stehen die Chancen auch hoch, dass dort eine Polyfuse dauerhaft schlechter leitet, als anfangs, so dass sie nur noch für kleine Verbraucher wie Mäuse taugt.
$ lsusb Bus 020 Device 030: ID 0483:374b STMicroelectronics ST-LINK/V2.1 Jetzt muß ich noch den device node finden. @stefanus: Da hing monatelang eine WD Elements 5TB dran. Im Moment ein Miniusb-Kabel 80cm (wo gibt's kurze Mini-USB Kabel?) Ja, meiner Skizze oben kann man entnehmen, daß beide Boards an dem Kabel hängen.
Aus dem Output von $ system_profiler SPUSBDataType kann ich Folgendes entnehmen: STM32 STLink: Product ID: 0x374b Vendor ID: 0x0483 (STMicroelectronics) Version: 1.00 Serial Number: 066CFF485153826687123124 Speed: Up to 12 Mb/s Manufacturer: STMicroelectronics Location ID: 0x14200000 / 30 Current Available (mA): 500 Current Required (mA): 400 Extra Operating Current (mA): 0 Media: microcontroller: Capacity: 41 KB (40.960 bytes) Removable Media: Yes BSD Name: disk2 Logical Unit: 0 Partition Map Type: Unknown S.M.A.R.T. status: Verified USB Interface: 1 Wo ich allerdings Fehlermeldungen finde, weiß ich momentan nicht. Gleich nach dem Sterben des OpenOCD-Prozesses sehe ich in /var/log/system.log: Apr 1 20:31:13 Christophs-MacBook-Pro com.apple.xpc.launchd[1] (com.apple.mdworker.shared.06000000-0300-0000-0000-000000000000[9876]): Service exited due to SIGKILL | sent by mds[95] Apr 1 20:31:56 Christophs-MacBook-Pro com.apple.xpc.launchd[1] (com.apple.mdworker.shared.08000000-0000-0000-0000-000000000000[9865]): Service exited due to SIGKILL | sent by mds[95] Apr 1 20:32:07 Christophs-MacBook-Pro com.apple.xpc.launchd[1] (com.apple.mdworker.shared.0A000000-0600-0000-0000-000000000000[9888]): Service exited due to SIGKILL | sent by mds[95] Apr 1 20:32:14 Christophs-MacBook-Pro AMPDeviceDiscoveryAgent[633]: Entered:_AMMuxedDeviceDisconnected, mux-device:1082 Apr 1 20:32:14 Christophs-MacBook-Pro AMPDevicesAgent[1017]: Entered:_AMMuxedDeviceDisconnected, mux-device:1082 Apr 1 20:32:14 Christophs-MacBook-Pro AMPDevicesAgent[1017]: Entered:__thr_AMMuxedDeviceDisconnected, mux-device:1082 Apr 1 20:32:14 Christophs-MacBook-Pro AMPDeviceDiscoveryAgent[633]: Entered:__thr_AMMuxedDeviceDisconnected, mux-device:1082 Apr 1 20:32:14 Christophs-MacBook-Pro AMPDevicesAgent[1017]: tid:15fb7 - Mux ID not found in mapping dictionary Apr 1 20:32:14 Christophs-MacBook-Pro AMPDeviceDiscoveryAgent[633]: tid:1238b - Mux ID not found in mapping dictionary Apr 1 20:32:14 Christophs-MacBook-Pro AMPDevicesAgent[1017]: tid:15fb7 - Can't handle disconnect with invalid ecid Apr 1 20:32:14 Christophs-MacBook-Pro AMPDeviceDiscoveryAgent[633]: tid:1238b - Can't handle disconnect with invalid ecid Ob das was damit zu tun hat, kann ich im Moment nicht agen.
Gast
#7021661
Christoph K. schrieb: > $ lsusb > Bus 020 Device 030: ID 0483:374b STMicroelectronics ST-LINK/V2.1 Das bedeutet vermutlich /dev/bus/usb/020/030 oder /dev/usb/020/030.
A. B. schrieb: > Christoph K. schrieb: >> $ lsusb >> Bus 020 Device 030: ID 0483:374b STMicroelectronics ST-LINK/V2.1 > > Das bedeutet vermutlich /dev/bus/usb/020/030 oder /dev/usb/020/030. Gibt's nicht. Ich beschränke mich jetzt erst einmal auf den Fall DISCOVERY-Board mit on-Board MCU, also CN3 enabled, um zu schauen, welche Devices da angelegt werden und um die ganze Diskussion über ungültige CPU-IDs mal außen vor zu lassen, denn irgendwie funktioniert etwas grundsätzlich nicht. Die folgenden Devices erscheinen im Moment, wo ich das DISCVOVERY-Board anschließe:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
Dabei erscheint auch auf dem Desktop ein Volume DIS_F407VG. Als ich das DIY-MORE Board noch mit angeschlossen hatte, war der Effekt so, daß das Volume auf dem Desktop nicht sofort erschien, sondern erst nachdem ich OpenOCD oder st-info --probe einmal aufgerufen hatte und danach war zusätzlich ein FAIL.TXT in dem Volume erschienen (siehe Bild). Es scheint also vorrangig erst mal ein Stromversorgungproblem zu sein. Habe noch einen Sabrent 4-fach HUB, an den ich ein Netzteil anschießen kann. Werde das mal versuchen. Auch werde ich mir mal ein kurzes Mini-USB-Kabel basteln, obwohl das ja immer häßlich ist, diese Stecker aufzuschneiden (weiß jemand eine Quelle für ein superkurzes Mini-USB-Kabel?). Ich werde also jetzt erst mal die physikalischen Voraussetzungen in Ordnung bringen. Danke erst mal für die Hilfe und schönes Wochenende. Grüße Christoph
Angehängte Dateien:
Gast
#7021809
Christoph K. schrieb: > weiß jemand eine Quelle für ein superkurzes Mini-USB-Kabel? Du brauchst kein kurzes Kabel, sondern einfach nur ein gutes. Das sieht man nicht jedem Kabel von außen an. Dick ist nicht immer gut. Außwrdem leiern die Steckverbinder mit der Zeit aus. Da geht Probieren geht über Studieren. Und du solltest zur Kenntnis nehmen, dass drei Mikrocontroller plus ein bisschen drumherum an einem USB Port schon grenzwertig sind. Bei mir klappt das auch nur mit Glück. Lösung: Netzteile benutzen
Stefan ⛄ F. schrieb: > Christoph K. schrieb: >> weiß jemand eine Quelle für ein superkurzes Mini-USB-Kabel? > > Du brauchst kein kurzes Kabel, sondern einfach nur ein gutes. Das sieht > man nicht jedem Kabel von außen an. Dick ist nicht immer gut. Außwrdem > leiern die Steckverbinder mit der Zeit aus. Da geht Probieren geht über > Studieren. ... > > Lösung: Netzteile benutzen Habe jetzt ein 5V/2,5A Netzteil an den Hub angeschlossen. Dort unter Last des DISC0 Leerlauf 4,98 V. Am DISCO-Board kommen 4,64 V an. 93 cm USB-Kabel dazwischen.
Gast
#7021880
Christoph K. schrieb: >
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
Zumindest null, io8logtemp, tty.usbmodem14203, cu.usbmodem14203, ptmx, ttys002 gehören ganz sicher nicht zu dem STLink. Die sind sicher auch vorher schon da. Das erhärtet den Verdacht auf ein Problem mit der Stromversorgung und/oder Kabel, sprich ein Hub oder der USB-Controller macht einen Reset wg. Überstrom oder sonst eines Fehlers. Ganz "unten" muss aber ein Device-Node vom STLink sein (wenn er überhaupt funktioniert), "darüber" dann zusätzlich ttyUSB?, ttyACM?, sdc? oder disk?, je nach Treiber, der sich da angesprochen fühlt.
A. B. schrieb: > Christoph K. schrieb: >>
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
> > Zumindest null, io8logtemp, tty.usbmodem14203, cu.usbmodem14203, ptmx, > ttys002 > gehören ganz sicher nicht zu dem STLink. Die sind sicher auch vorher > schon da. Das erhärtet den Verdacht auf ein Problem mit der Nein, die werden alle genau mit dem Einstecken des STLINK kreiiert. Nach Ausstöpseln sind die weg. tty und cu sind ja die serial ports, die im STLINK emuliert werden. disk2 und rdisk2 sind die Volumes (virtuelle Filesysteme), die man ja auch io8logtemp ist vielleicht ein logger, den man anzapfen kann. $ cat /dev/io8logtemp Wie gesagt, alle Devices sind korreliert mit Anschließen des STLINK/DISCO-Boards. Komme zurück, wenn ich mein Kabel/Stromversorgungsproblem bereinigt habe.
Gast
#7021960
Christoph K. schrieb: > Nein, die werden alle genau mit dem Einstecken des STLINK kreiiert. > Nach Ausstöpseln sind die weg. > > tty und cu sind ja die serial ports, die im STLINK emuliert werden. > disk2 und rdisk2 sind die Volumes (virtuelle Filesysteme), die man ja > auch > > io8logtemp ist vielleicht ein logger, den man anzapfen kann. Nun, da sind halt die Namenskonvetionen beim Mac etwas anders als beim "normalen" Linux ... OpenOCD setzt aber NICHT auf denen auf, das virtuelle Filesytem (fürs "Drag and Drop") bzw. der serielle Port haben damit erst mal nichts zu tun, sondern nur auf den primären Device Node, und auch nur dessen Berechtigungen sind relevant. Unter Linux geht das über die "libusb", wie das bei Max aussieht, weiß ich nicht. Vielleicht fehlt da auch genau diese Bibliothek: ldd /usr/bin/openocd | grep usb libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x00007fa270480000)
libusb wird auf macOS auch benutzt. Bin im Moment nicht am Rechner, weshalb ich nicht nachgucken kann, aber ich hatte beide, eine 1.0.24 und 1.0.25 probiert. ( Version nur so ungefähr aus dem Kopf) Irgendwo habe ich aufgeschnappt, daß die Ansprache des ST-LINK jetzt neuerdings über „native USB commands“ oder auf USB Level laufe. Kann mich auch irren und wenn ja, wie lief es vorher? Aber das könnte auch Ursach von Problemen sein. Vielleicht sollte ich mir mal auf Linux ein System hochziehen, mit dem ich vergleichen kann.
Wenn eine shared lib fehlte, so würde das gemeldet. ldd gibt‘s unter macOS nicht.
Habe jetzt auf meinem Lenovo-Notebook ( Ubuntu 21.10) stlink installiert. Sowohl das apt-Paket stlink v1.6.1 wie auch das von github runtergeladene und auf dem Notebook kompilierte v1.7.0-186-gc4762e6. DISCO Board über das neue gekürzte Mini-USB-Kabel an den SABRENT 4xHUB angeschlossen, HUB mit eigener 5V/2,5A Stromversorgung verbunden. An Notebook angeschlossen. Onboard MCU getrennt und ein zweites DISCO Board angeschlossen über SWD (SWCLK und SWDIO jeweils an PA14 und PA13 des Master DISCO Boards) Auf Linux:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
Nun am Mac:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
Soweit wird also die Target MCU erkannt. Jetzt das DIY-MORE Board angeschlossen an SWD:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
Gast
#7023134
Da kommt offenbar gar nichts, daher funktioniert die SWD-Kommunikation wohl gar nicht. Nicht korrekt angeschlossen, uC kaputt ... OpenOCD ist (mit dem -d3) etwas "geschwätziger", da gibt's vielleicht mehr Infos. Ansonsten hilft wohl nur LA und/oder Scope dran ...
A. B. schrieb: > Da kommt offenbar gar nichts, daher funktioniert die SWD-Kommunikation > wohl gar nicht. Nicht korrekt angeschlossen, uC kaputt ... > OpenOCD ist (mit dem -d3) etwas "geschwätziger", da gibt's vielleicht > mehr Infos. > > Ansonsten hilft wohl nur LA und/oder Scope dran ... Hatte das Scope (Tek 2465B) schon mal dran und sah Pulse, einen ca. 500 µS langen burst von Clockpulsen und dazu Daten (alle Pulse negative Logik). An Clock sah ich Rechtecksignale von ca. 750 nS Periodenlänge, Taktverhältnis ca. 1:1. Immer getriggert mit Ausführen des Kommandos st-info --probe Was gibt's übrigens an preiswerten LA-Lösungen? Habe jetzt OpenOCD mal unter Linux installiert (von github geladen) und gebaut. Hier ist der Debug Log von der Situation "nicht funktionierendes Target an DISCO" (unter Linux). Noch ein Gedanke: Könnte es sein, daß das Target so programmiert ist, daß die PA14/PA13 nicht auf SWDCLK/SWDIO reagieren? Ich könnte schwören, daß ich ganz am Anfang meiner Odyssee das Target einmal mit STM32CubeIDE programmiert hatte.
Gast
#7023301
Christoph K. schrieb: > Hatte das Scope (Tek 2465B) schon mal dran und sah Pulse, einen ca. 500 > µS langen burst von Clockpulsen und dazu Daten (alle Pulse negative > Logik). An Clock sah ich Rechtecksignale von ca. 750 nS Periodenlänge, > Taktverhältnis ca. 1:1. Immer getriggert mit Ausführen des Kommandos > st-info --probe SWCLK sagt nicht viel aus, weil das ja nur vom STLink zum Target geht, und auch bei SWDIO ist natürlich die "Antwort" vom Target interessant. Man muss also ein ganzes Paket oder noch besser mehrere ansehen, um zu erkennen, ob das Target überhaupt antwortet. Für die Interpretation: ARM IHI 0031D, B4.2 Insbesondere muss vom Target immer ein Ack kommen. > Was gibt's übrigens an preiswerten LA-Lösungen? Die Salea-Clones, 8-Kanal bis 24MHz, mit sigrok. > Habe jetzt OpenOCD mal unter Linux installiert (von github geladen) und > gebaut. > > Hier ist der Debug Log von der Situation "nicht funktionierendes Target > an DISCO" (unter Linux). Die wesentliche Info ist "stlink_usb.c:1090 stlink_usb_error_check(): STLINK_JTAG_GET_IDCODE_ERROR stlink_usb.c:3752 stlink_open(): init mode failed (unable to connect to the target)" Also keine Antwort vom Target. Hm, ich würde mal direkt an die Beinchen vom Target gehen (von dort zur Pfostenleiste durchklingeln), vielleicht unterbrochene Leiterbahn, Lötstelle defekt, oder vielleicht stimmt der Aufdruck auf der Platine gar nicht. Auch direkt am Gehäuse Masse und Versorgung messen. "stlink_usb.c:1474 stlink_usb_check_voltage(): Target voltage: 2.910940" Die 2.9V finde ich etwas mau, da würde ich schon deutlich über 3V erwarten. Nicht dass der STM32F407 nicht damit funktionieren würde, aber da sind doch sicher überall 3.3V-Regler drauf? Da ja vom Target nichts kommt, wird es wohl ein verhältnismäßig "banaler" Fehler sein. Was nicht heißen soll, dass der leicht zu finden ist.
A. B. schrieb: ... > Da ja vom Target nichts kommt, wird es wohl ein verhältnismäßig > "banaler" Fehler sein. Was nicht heißen soll, dass der leicht zu finden > ist. Ich habe zwei von den Target Boards (mit Pfostenleisten bestückt und noch weitere 10 unbestückte), da müßte schon bei beiden eine Unterbrechung sein. BOOT0 Pin ist auf GND gejumpert. (siehe Board Schaltung weiter oben). BOOT1 Pin offen.
Christoph K. schrieb: > Könnte es sein, daß das Target so programmiert ist, > daß die PA14/PA13 nicht auf SWDCLK/SWDIO reagieren? Ja.
Bauform B. schrieb: > Christoph K. schrieb: >> Könnte es sein, daß das Target so programmiert ist, >> daß die PA14/PA13 nicht auf SWDCLK/SWDIO reagieren? > > Ja. Das ist ja interessant. Und wie bekommt man es wieder dahin?
Gast
#7023435
Bauform B. schrieb: > Christoph K. schrieb: >> Könnte es sein, daß das Target so programmiert ist, >> daß die PA14/PA13 nicht auf SWDCLK/SWDIO reagieren? > > Ja. Aber dass die "ab Werk" so programmiert sind??? Möglich schon, aber doch recht unwahrscheinlich. Und selbst wenn: NRST auf low halten, dann müsste es doch gehen. Beim F407 kann man NRST noch nicht totlegen wie beim G0 etwa. Auch wenn das eine Fälschung sein sollte: Auch die Clones sollten über SWD ansprechbar sein. Ein "leeres" Gehäuse sollte sich auch leicht feststellen lassen: Multimeter auf Diodentest, '+'-Kabel an GND und dann alle GPIOs abklappern, da müssten jeweils 600 bis 700mV zu messen sein, während es bei VDD deutlich weniger sein sollte, so um die 500mV.
Gast
#7023483
A. B. schrieb: > Nicht dass der STM32F407 nicht damit funktionieren würde, aber da sind > doch sicher überall 3.3V-Regler drauf? Deswegen hatte ich die Stromversorgung weiter oben schon einmal in Frage gestellt. Schon im vorherigen Thread hatte er dieses Problem angedeutet: Christoph K. schrieb: > Info : Target voltage: 2.911243 Solange die Stromversorgung nicht in Ordnung ist, braucht man an anderen Stellen gar nicht weiter zu suchen. Auf meinen Vorschlag ist er ja auch eingegangen, allerdings vermisse ich nach dem Tausch von Kabeln und Netzteilen eine Kontrolle, ob die Spannung damit nun wirklich in Ordnung ist. Bei den Zickereien die er nun hat, würde ich mich nicht einmal mehr auf ein simples Multimeter verlassen, sondern die Versorgungsspannung mit einem Oszilloskop kontrollieren (ob sie in Aktion stabil ist).
A. B. schrieb: > Bauform B. schrieb: >> Christoph K. schrieb: >>> Könnte es sein, daß das Target so programmiert ist, >>> daß die PA14/PA13 nicht auf SWDCLK/SWDIO reagieren? >> >> Ja. > > Aber dass die "ab Werk" so programmiert sind??? Möglich schon, aber doch > recht unwahrscheinlich. Und selbst wenn: NRST auf low halten, dann > müsste es doch gehen. Beim F407 kann man NRST noch nicht totlegen wie > beim G0 etwa. > Auch wenn das eine Fälschung sein sollte: Auch die Clones sollten über > SWD ansprechbar sein. Ein "leeres" Gehäuse sollte sich auch leicht > feststellen lassen: Multimeter auf Diodentest, '+'-Kabel an GND und dann > alle GPIOs abklappern, da müssten jeweils 600 bis 700mV zu messen sein, > während es bei > VDD deutlich weniger sein sollte, so um die 500mV. Zwischenbericht: Nucleo-Board angeschlossen, 2 Leitungen von SWD verbunden zum Target Target gepowert vom USB-FTDI Stick (TTL-Level). Kein extra Netzteil. $ st-flash erase st-flash 1.7.0 2022-04-04T11:35:41 INFO common.c: F4xx: 192 KiB SRAM, 1024 KiB flash in at least 16 KiB pages. Mass erasing............. $ ./st-info --probe #(neueste stlink verson) Failed to parse flash type or unrecognized flash type detected chip_id parametres # Device Type: STM32F4x5_F4x7 # Reference Manual: RM0090 // RM0090 (Rev. 2) # chip_id 0x413 flash_type 3 flash_size_reg 0x1fff7a22 flash_pagesize 0x4000 sram_size 0x30000 bootrom_base 0x1fff0000 bootrom_size 0x7800 option_base 0x40023c14 option_size 0x4 flags 2 Found 1 stlink programmers version: V2J37S26 serial: 0679FF525056805035012236 flash: 1048576 (pagesize: 16384) sram: 196608 chipid: 0x413 detected chip_id parametres # Device Type: STM32F4x5_F4x7 # Reference Manual: RM0090 // RM0090 (Rev. 2) # chip_id 0x413 flash_type 3 flash_size_reg 0x1fff7a22 flash_pagesize 0x4000 sram_size 0x30000 bootrom_base 0x1fff0000 bootrom_size 0x7800 option_base 0x40023c14 option_size 0x4 flags 2 dev-type: STM32F4x5_F4x7 Test mit openocd -> angehängte Log-Datei. Übrigens, jetzt 3.22 V Nachtrag: zurück zum DISCO-Board: die alten Probleme. Voltage 2.98 V (obwohl Versorgung des Targets genauso)
Gast
#7024023
Christoph K. schrieb: > Übrigens, jetzt 3.22 V > zurück zum DISCO-Board: Voltage 2.98 V Das ist die Problemursache. Du hast keine stabile ausreichend belastbare Stromversorgung. Irgendwo fällt bei dir unter Last signifikant Spannung ab. Du könntest zur Gegenprobe einfach mal noch mehr Last dran hängen, zum Beispiel einen 47Ω Widerstand. Wenn sie dann noch weiter absackt, hast du den Beweis. 100mA Reserve muss nämlich drin sein, sonst ist eh alles dem Zufall überlassen.
Gast
#7024064
Christoph K. schrieb: > Test mit openocd -> angehängte Log-Datei. Liefert auch die korrekte ID Debug: 292 135 stlink_usb.c:1679 stlink_usb_idcode(): IDCODE: 0x2BA01477 Also scheint da jetzt alles ok zu sein. > Übrigens, jetzt 3.22 V > > Nachtrag: zurück zum DISCO-Board: die alten Probleme. Voltage 2.98 V > (obwohl Versorgung des Targets genauso) Die 0.3V weniger sind eigentlich unwichtig, aber das legt die Vermutung nahe, dass die Versorgung schon unter geringer Last einbricht - und das war's dann. Vielleicht ist der Regler auf dem Disco-Board kaputt, überlastet oder wird nicht ausreichend gekühlt.
Neuer Stand: 1. Neues kurzes USB Kabel (15cm) bekommen 2. 3 DIYMORE Boards ausprobiert und alle geben bei st-info --probe vernünftigen Output von sich.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
3. openocd meldet allerdings:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
Und ich bekomme folgenden Fehler:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
Ich habe jetzt den NRST vom SWD-Interface des DISCO-Boards (5) mit dem Reset-Schalter des DIYMORE-Boards verbunden und zum ersten Mal konnte ich das Blinky-Programm erfolgreich flashen.
Angehängte Dateien:
Gast
#7031387
Christoph K. schrieb: > zum ersten Mal konnte ich das Blinky-Programm erfolgreich flashen. Vermutlich war auf dem Board ein Programm drauf, das die SWD Schnittstelle deaktivierte. Die von Cube MX generierten Programme machen das alle standardmäßig. Allerdings widerspricht dies dem: > 3 DIYMORE Boards ausprobiert und alle geben bei > st-info --probe vernünftigen Output von sich. Vielleicht helfen die die folgenden Hinweise, das "Problem" besser zu verstehen: http://stefanfrings.de/stm32/cube_ide.html#flash
Stefan ⛄ F. schrieb: > Vielleicht helfen die die folgenden Hinweise, das "Problem" besser zu > verstehen: http://stefanfrings.de/stm32/cube_ide.html#flash Danke für den Hinweis. Deine Anleitung hat jetzt meine Neugier dahingehend geweckt, doch mal SWD-Trace Messages auszuprobieren. Habe in die Blinky-Mainloop
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
eingebaut und dann die Funktion ITM_SendString(*str) implementiert.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
In der Debug-Konfiguration CPU-Clock 8MHz eingestellt Port 0 ausgewählt und auf den roten Knopf gedrückt. Es kommt aber keine Trace-Meldung in der SWV-ITM Dataconsole.
Machst du C oder C++? Bei C++ könnte es zwei verschiedene ITM_SendString geben (für const und nicht-const).
Gast
#7031686
Christoph K. schrieb: > Es kommt aber keine > Trace-Meldung in der SWV-ITM Dataconsole. Hast du den TRACESWO Pin denn mit dem Debugger verbunden? Hast du das Feature in der "Debug Configuration" eingeschaltet ([x] Enable)? Hast du alternativ das ST-Link Utility versucht? Warum zeigst du keine Fotos vom Aufbau und Screenshots von deinen Einstellungen?
SWO Pin (6) am SWD Interface ist nicht angeschlossen. Wüßte jetzt im Moment auch nicht, wo am Target. Ich meinte übrigens nicht Trace Messages, sondern Messages auf der ITM_Dataconsole.
Angehängte Dateien:
-
IMG_2762.jpg
(240 KB)
-
Bildschirmfoto_2022-04-11_um_19.07.38.png
(340 KB)
Gast
#7031719
Christoph K. schrieb: > SWO Pin (6) am SWD Interface ist nicht angeschlossen. Wüßte jetzt im > Moment auch nicht, wo am Target. Dann kann das natürlich auch nicht funktionieren! Welcher Pin TRACESWO ist, wirst du selbst herausfinden.
Stefan ⛄ F. schrieb: > Christoph K. schrieb: >> SWO Pin (6) am SWD Interface ist nicht angeschlossen. Wüßte jetzt im >> Moment auch nicht, wo am Target. > > Dann kann das natürlich auch nicht funktionieren! Welcher Pin TRACESWO > ist, wirst du selbst herausfinden. Habe keine Idee, wo am STM32F407 des DIYMORE Boards der SWO pin sein soll. Ich lese was vom Arm CoreSight M4 Debug Block. Am nächsten käme da von den Pinbezeichnungen PC11/SDIO. Muß passen.
Christoph K. schrieb: > Habe keine Idee, wo am STM32F407 des DIYMORE Boards der SWO pin sein > soll. > Ich lese was vom Arm CoreSight M4 Debug Block. Am nächsten käme da von > den Pinbezeichnungen PC11/SDIO. Muß passen. Nein, passt gar nicht. Es gibt ein Datenblatt von STM namens DS8626. Da steht auf Seite 58 in Tabelle 7 etwas von PB3 (JTDO/TRACESWO). Das wäre eher ein Kandidat.
Hat dein Board (auf dem es nicht klappt) einen STLink-Nachbau drauf? Oder nimmst du einen echten ST-Link? Bei einem echten ST-Link müsste man das TRACESWO, also in dem Fall PB3, zum ST-Link Pin 13 des 20-poligen JTAG/SWD-Anschlusses ziehen (siehe UM1075 Table 4). Der STLink verwurstet das dann weiter. Auf dem F407-Diso-Board wird das intern gemacht. Da geht TRACESWO vom F407 über eine Lötbrücke SB12, die standardmäßig gesetzt ist (siehe UM1472 Table 6) in den STM32F103, der STLink spielt. Man kann den ST-Link-Teil vom DISCO jetzt auch im Prinzip nehmen, um einen STM32 außerhalb des DISCO zu nutzen über SWD, indem man die Jumper von CN3 entfernt und den externen STM32 an CN1 auf dem DISCO-Board anschließt. Ich glaube aber nicht, daß man dabei den SWO nutzen kann, weil die CN3 nicht den TRACESWO vom F407 auf dem DISO trennen (nehme ich zumindest an). Vielleicht geht es, wenn man SB12 auf dem DISCO entfernt und den TRACESWO von deinem Board (PB3) mit Pin6 von CN1 verbindet. Müsste man im Schaltplan vom DISCO schauen, ob das dann zu dem STM32F103 geleitet wird, der den STLink bildet. Den Schaltplan gibt es bei ST (Stichwort MB997, weil das die Platine vom Disco ist, ggf. Version des MB997 auf der Platine vom DISCO nachschauen.) Wenn dein Board einen STLink mehr oder weniger gut nachbildet und du den nimmst zum Debuggen, musst du bei dem herausfinden was er mit dem TRACESWO macht. Wenn es dazu ordentliche Doku gibt, sollte man das darin finden. Entsprechend falls du einen STLink-Klon nimmst. Ob der SWO durchleitet, würde ich nicht unterschreiben. Auf jeden Fall sollte man mit einem Logic Analyzer oder Oszi oder notfalls einer LED erstmal sehen, ob an PB3 etwas ankommt. Im nächsten Schritt musst du sehen, wie du das dann bis zum PC bekommst.
Gast
#7032054
Klaus W. schrieb: > Es gibt ein Datenblatt von STM namens DS8626. > Da steht auf Seite 58 in Tabelle 7 etwas von PB3 (JTDO/TRACESWO). > Das wäre eher ein Kandidat. Das hätte er selbst heraus finden sollen. Wir sind doch keine Babysitter!
Gast
#7032056
Klaus W. schrieb: > Ich glaube aber nicht, daß man dabei den SWO nutzen kann, weil die CN3 > nicht den TRACESWO vom F407 auf dem DISO trennen Das ist egal, solange der Target µC den Pin nicht aktiv ansteuert. Man kann ja ein entsprechendes Programm drauf laden, oder seinen Reset Eingang fest klemmen.
Klaus W. schrieb: > Machst du C oder C++? > Bei C++ könnte es zwei verschiedene ITM_SendString geben (für const und > nicht-const). C, und hover über die Funktion liefert nur eine Repräsentanz. Status im Moment: externes Target Board mit PB3 an SWO (SWD CN2, pin 6) verbunden. In der SWV Console erscheinen Debugmeldungen, aber noch als Hieroglyphen. Clockrate? Allerdings wird STM32CubeIDE unheimlich busy und friert ein. EDIT: Klappt jetzt. Ich bekam eine Fehlermeldung "Trace buffer full". Aber es hat jetzt funktioniert mit Angabe der echten CPU-Clockrate (168MHz). Neben Stefanus Anleitung fand ich diese - https://www.codeinsideout.com/blog/stm32/swv/ auch ganz nützlich. Da steht nämlich, daß man die CPU-Clockrate nehmen soll.
Gast
#7032120
Christoph K. schrieb: > Clockrate? Vermutlich liegt es daran. Das ist ja ein serielles Protokoll ähnlich UART. Wobei die Schnittstelle einzelne Buchstaben als 32bit überträgt. Also wenn dein Programm zwischen jedem richtigen Buchstaben drei Hieroglyphen anzeigt, ist es nur ein Darstellungsfehler. > Neben Stefanus Anleitung fand ich diese (link) auch ganz nützlich. > Da steht nämlich, daß man die CPU-Clockrate nehmen soll. Habe ich das nicht ebenfalls geschrieben? "Aktiviere im Debugger Tab die rot markierte Option und stelle die Taktfrequenz des Mikrocontrollers ein"
Stefan ⛄ F. schrieb: > Christoph K. schrieb: >> Clockrate? > > Vermutlich liegt es daran. Das ist ja ein serielles Protokoll ähnlich > UART. Wobei die Schnittstelle einzelne Buchstaben als 32bit überträgt. > Also wenn dein Programm zwischen jedem richtigen Buchstaben drei > Hieroglyphen anzeigt, ist es nur ein Darstellungsfehler. > >> Neben Stefanus Anleitung fand ich diese (link) auch ganz nützlich. >> Da steht nämlich, daß man die CPU-Clockrate nehmen soll. > > Habe ich das nicht ebenfalls geschrieben? > "Aktiviere im Debugger Tab die rot markierte Option und stelle die > Taktfrequenz des Mikrocontrollers ein" Hast ja recht. Da steht ja auch "Core Clock". Mir erschienen nur die 8MHz in der Voreinstellung etwas ungewöhnlich (weil die Quarzclock 8 MHz) ist, weshalb ich da zuerst 8MHz eingestellt hatte. Meine CPU in meinem Testprogramm ist aber auf 168MHz eingestellt.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
Trotz dieser relativ niedrigen Rate von Meldungen kriege ich einen Tracebuffer Überlauf im CudeIDE (s. Bild).
Angehängte Dateien:
Gast
#7032159
Christoph K. schrieb: > Hast ja recht. Da steht ja auch "Core Clock". Mir erschienen nur die > 8MHz in der Voreinstellung etwas ungewöhnlich (weil die Quarzclock 8 > MHz) ist, weshalb ich da zuerst 8MHz eingestellt hatte. Bei den µC für dich ich das schrieb sind 8 Mhz die Standard Taktfrequenz nach einem Reset, sofern man keine PLL aktiviert. Ist bei deinem vermutlich auch so. > kriege ich einen Tracebuffer Überlauf im CudeIDE Da kann ich lieder nicht helfen, das ist mir noch nie passiert. Du hast doch schon reichlich Delays eingebaut. Vielleicht kommst du mit OpenOCD und Ausgabe in separatem Terminalfenter besser klar. Ich habe das auf der selben Seite beschrieben.
(anbei noch Doku) Wenn ich in Preferences->STM32Cube->Serial Wire Viewer nachschaue (anderer Ort als Window->Preferences, aber da Mac...), steht dort schon 2000000 (2MB?) Das ist doch schon eine ganze Menge für so ein paar Meldungen. Manchmal ist weniger ja mehr :)
Angehängte Dateien:
-
IMG_2844.jpg
(220 KB)
Gast
#7032217
Christoph K. schrieb: > Das ist doch schon eine ganze Menge für so ein paar Meldungen. Ja, das entspricht etwa 1/2 Bibel.
Soeben kam übrigens die Logic Probe Sigrok NanoDLA v1.2. (am 3.4. bestellt) Enttäuschung aber groß: wird von Logic 2 2 nicht erkannt.
Habe den SWV Tracebuffer auf 10.000.000 erhöht und bis jetzt Ruhe. Zu früh gefreut. Läuft jetzt etwas später über und danach ist die Debugsession auch im Eimer.
Christoph K. schrieb: > Habe den SWV Tracebuffer auf 10.000.000 erhöht und bis jetzt Ruhe. > Zu früh gefreut. Läuft jetzt etwas später über und danach ist die > Debugsession auch im Eimer. Fehler gefunden, warum der Tracebuffer überlief (man soll nie etwas einschalten, über das man sich nicht von vornherein im klaren ist): Ich hatte in den Werkzeugeinstellungen für die SWV ITM Dataconsole auch "Traceevents" mit angeklickt. Die wurden dann wahrscheinlich zuhauf generiert und brachten so den Buffer zum Überlauf.
Gast
#7033202
Christoph K. schrieb: > Fehler gefunden Es ist immer besser die Problemursache zu finden, anstatt einen Workaround anzuwenden bei dem man nie sicher sein, wie lange er funktioniert. Der TRACESWO Pin ist ein guter Kandidat für eine Power-LED. Solange kein Debugger benutzt wird, kannst du damit eine LED ansteuern um "ich lebe" anzudeuten. Wenn der Debugger dran hängt, verwandelt sich der Pin in einen seriellen Port für die Trace Meldungen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.