STM32 ST-LINK V2

[Walt N. (belayason)]

Guten Morgen,

bis jetzt habe ich mit der AC6 for STM32 meine mikrocontroller 
Programmiert. Jetzt bin ich umgestiegen auf die STM32CudeIDE um die 
Initialisierung durch STM32CubeMX besser aktuell halten zu können. Ich 
habe mein Programm in die STM32CudeIDE von Hand migriert. Bauen 
funktioniert ohne Fehler und Warnungen. Jedoch kommen jetzt Probleme mit 
meinem ST-Link/V2. Beim ersten flash versuch, wurde eine alte Firmware 
nachgewiesen die ich durch den Updater aktualisiert habe. Danach wurde 
der flash versuch erneut gestartet, dies funktioniert aber nicht (siehe 
Anhang).

Ich hatte die Befürchtung, dass das Update die Ursache ist. Aber mit dem 
AC6 funktioniert der ST-Link/V2 weiterhin tadellos. Hatte jemand schon 
das gleiche Problem?

[Johannes S. (Gast)]

die CubeIDE nutzt einen anderen Programmer, und die neueren 
CubeProgrammer wollen auch neuere Firmware haben. Die sperrt andere 
(nicht STM) Devices aus die man vorher damit programmieren konnte.

[Walt N. (belayason)]

Johannes S. schrieb:
> nicht STM

Es Handelt sich bei dem Programmer um einen originalen ST-LINK/V2 ISOL, 
wenn deine Aussage daraus hinaus laufen sollte.

[Johannes S. (Gast)]

Man konnte mit dem originalen STLink auch Nordic nRF und andere 
programmieren, siehe https://github.com/EmBitz/EBlink 'Warning'.
Wird hier nicht stören, ist für mich aber ein Zeichen das die 
unterschiedlichen IDE auch unterschiedliche Programmer nutzen, AC6 
vermutlich das ältere STUtil.

[Walt N. (belayason)]

Johannes S. schrieb:
> Man konnte mit dem originalen STLink auch Nordic nRF und andere
> programmieren

Bei dem zu programmierenden Device handelt es sich um einen STM32F411RE. 
Also dürfte das schonmal nicht das Problem sein. Und hast du einen 
Ansatz wo ich vielleicht suchen sollte?

[Johannes S. (Gast)]

es könnte ein anderes Standardproblem sein: wurde in der CubeMX Konfig 
das SWD aktiviert? Ist per default abgeschaltet. Dann sollte allerdings 
flashen möglich sein und nicht der gdb abstürzen.

Ansonsten nochmal neu starten und kontrollieren ob auch alles beendet 
wurde und nicht noch ein gdbserver lief?

[Stefan F. (Gast)]

In der "Debug configuration" kannst du von "ST-Link GDB server" auf 
"openocd" umschalten. Dann geht es vielleicht besser.

Siehe Screenshots auf http://stefanfrings.de/stm32/cube_ide.html#debug

[Walt N. (belayason)]

Stefan ⛄ F. schrieb:
> openocd

Open On-Chip Debugger 0.11.0-rc2+dev-00037-g4c4dbd9 (2021-02-09-13:39)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.254665
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x2ba01477
Info : STM32F411RETx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : STM32F411RETx.cpu: external reset detected
Info : starting gdb server for STM32F411RETx.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800471c msp: 0x20020000
configuring PLL
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : device id = 0x10006431
Info : flash size = 512 kbytes
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800471c msp: 0x20020000
configuring PLL
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
shutdown command invoked
Info : dropped 'gdb' connection
shutdown command invoked

Das spuckt er mir jetzt aus

[Stefan F. (Gast)]

Sieht danach aus, dass SWD auf dem Target deaktiviert ist oder dass er 
sich schlafen gelegt hat.

Versuche mal die Option "Connect on Reset" und betätige die Reset Taste 
manuell. Es ist ein bisschen Tricky, das richtige Timing zu finden.

Soweit ich weiß unterstützen alle STM32 dieses "Connect on Reset". In 
dieser Phase spielt es keine Rolle, was das Programm tut, denn es läuft 
ja nicht.

Oder du nimmst einen andere Programmier-Adapter, der einen Reset-Ausgang 
hat.

[RUD (Gast)]

Es gibt von ST noch die Software STM32Cube Programmer.
Vielleicht kannst du damit versuchen, ob du connecten kannst.
Falls es mit diesem funktionieren sollte, weisst du dann das es sich in 
der CubeIDE um ein Einstellungsproblem handelt.

[Stefan F. (Gast)]

Bei mir ist es eher anders herum. In der IDE geht es immer, im 
Cube-Programmer nur wenn er gerade Lust dazu hat.

[Stefan F. (Gast)]

Walt N. schrieb:
> Das spuckt er mir jetzt aus

Sieht eigentlich gut aus, oder? Ich sehe da keine Fehlermeldung.

[Walt N. (belayason)]

Stefan ⛄ F. schrieb:
> Sieht eigentlich gut aus, oder? Ich sehe da keine Fehlermeldung.

Im Anhang nochmal die ganze Wahrheit. Sorry, die Fehlermeldung kommt 
leider immer noch

[Walt N. (belayason)]

Stefan ⛄ F. schrieb:
> Oder du nimmst einen andere Programmier-Adapter, der einen Reset-Ausgang
> hat.

Der ST-Link/V2 ISOL hat einen Reset Ausgang

[Stefan F. (Gast)]

Walt N. schrieb:
> Im Anhang nochmal die ganze Wahrheit. Sorry, die Fehlermeldung kommt
> leider immer noch

Sieht mir eher nach einem Programmabsturz aus, der womöglich gar nichts 
mit deinem Programmieradapter/Target zu tun hat.

[Stefan F. (Gast)]

Walt N. schrieb:
> Der ST-Link/V2 ISOL hat einen Reset Ausgang

Ach ja, ich hatte den Asia-Stick im Sinn aber das war ein anderer 
Thread.

[Walt N. (belayason)]

Ich habe das Problem gelöst. In den Debug Konfigurationen habe ich 
Debugger->Configuration Script den Reset Moder auf "Software system 
reset" gestellt. Jetzt funktioniert es problemlos!

[Johannes S. (Gast)]

man kann noch probieren den Boot0 auf high pegel zu legen und dann 
einmal Reset drücken. Dann ist der µC im Bootloader und evtl. 
Programmfehler (falscher Clock, SWD abgeschaltet) wirken sich nicht aus.