Target mit SWD verbinden - "Vdd from Application" , GND?

[Christoph K. (chriskuku)]

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?

[Harry L. (mysth)]

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.

[A. B. (Gast)]

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???

[Christoph K. (chriskuku)]

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?

[Christoph K. (chriskuku)]

Neue Erkenntnis:

$ st-flash erase
st-flash 1.6.1
2022-03-31T12:24:49 WARN: unknown chip id! 0x374b
Failed to connect to target
$

Kann ich das irgendwie umgehen? Blackmagic?

[Christian G. (Gast)]

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)

[Bauform B. (bauformb)]

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?

[Harry L. (mysth)]

Oder auf dem Discovery den Debugger nicht von der internen MCU 
getrennt....

[Christoph K. (chriskuku)]

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.

[Christoph K. (chriskuku)]

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?

$ st-flash --debug erase
st-flash 1.6.1
2022-03-31T14:59:44 DEBUG: *** looking up stlink version
2022-03-31T14:59:44 DEBUG: st vid         = 0x0483 (expect 0x0483)
2022-03-31T14:59:44 DEBUG: stlink pid     = 0x374b
2022-03-31T14:59:44 DEBUG: stlink version = 0x2
2022-03-31T14:59:44 DEBUG: jtag version   = 0x27
2022-03-31T14:59:44 DEBUG: swim version   = 0x1b
2022-03-31T14:59:44 DEBUG: *** looking up stlink version
2022-03-31T14:59:44 DEBUG: st vid         = 0x0483 (expect 0x0483)
2022-03-31T14:59:44 DEBUG: stlink pid     = 0x374b
2022-03-31T14:59:44 DEBUG: stlink version = 0x2
2022-03-31T14:59:44 DEBUG: jtag version   = 0x27
2022-03-31T14:59:44 DEBUG: swim version   = 0x1b
2022-03-31T14:59:44 DEBUG: stlink current mode: mass
2022-03-31T14:59:44 DEBUG: JTAG/SWD freq set to 0
2022-03-31T14:59:44 DEBUG: *** set_swdclk ***
2022-03-31T14:59:44 DEBUG: stlink current mode: mass
2022-03-31T14:59:44 DEBUG: *** stlink_enter_swd_mode ***
2022-03-31T14:59:44 DEBUG: *** stlink_jtag_reset ***
2022-03-31T14:59:44 DEBUG: *** stlink_reset ***
2022-03-31T14:59:44 DEBUG: *** stlink_write_debug32 5fa0004 to 0xe000ed0c
2022-03-31T14:59:44 DEBUG: Loading device parameters....
2022-03-31T14:59:44 DEBUG: *** stlink_core_id ***
2022-03-31T14:59:44 DEBUG: core_id = 0x0000374b
2022-03-31T14:59:44 DEBUG: *** stlink_read_debug32 374b is 0xe0042000
2022-03-31T14:59:44 WARN: unknown chip id! 0x374b
Failed to connect to target
$

[Christoph K. (chriskuku)]

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.

[A. B. (Gast)]

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.

[Christoph K. (chriskuku)]

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:

2022-03-31T14:59:44 WARN: unknown chip id! 0x374b

Failed to connect to target

$

Starte ich OpenOCD in einem Terminalfenster, so steigt OpenOCD aus:

$ ./DEBUG
xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2022-03-25-19:34)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz

Erst mal soweit.
Warum steigt OpenOCD aus?

[Thomas Z. (usbman)]

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

[Christoph K. (chriskuku)]

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.

[Thomas Z. (usbman)]

wie oben geschrieben
google "Chip id 0x374b" bringt einiges zutage. Du bist nicht der 
einzige.

[Thomas Z. (usbman)]

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?

[Christoph K. (chriskuku)]

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

[Christoph K. (chriskuku)]

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.

[A. B. (Gast)]

Christoph K. schrieb:
> Starte ich OpenOCD in einem Terminalfenster, so steigt OpenOCD aus:
>
>

> $ ./DEBUG
> xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2022-03-25-19:34)
> Licensed under GNU GPL v2
> For bug reports, read
>   http://openocd.org/doc/doxygen/bugs.html
> Info : The selected transport took over low-level target control. The 
> results might differ compared to plain JTAG/SWD
> srst_only separate srst_nogate srst_open_drain connect_deassert_srst
> 
> Info : Listening on port 6666 for tcl connections
> Info : Listening on port 4444 for telnet connections
> Info : clock speed 2000 kHz
> 
> 
>

>
> 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".

[Christoph K. (chriskuku)]

A. B. schrieb:
> Christoph K. schrieb:
>> Starte ich OpenOCD in einem Terminalfenster, so steigt OpenOCD aus:
>>
>>

>> $ ./DEBUG
>> xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2022-03-25-19:34)
>> Licensed under GNU GPL v2
>> For bug reports, read
>>   http://openocd.org/doc/doxygen/bugs.html
>> Info : The selected transport took over low-level target control. The
>> results might differ compared to plain JTAG/SWD
>> srst_only separate srst_nogate srst_open_drain connect_deassert_srst
>>
>> Info : Listening on port 6666 for tcl connections
>> Info : Listening on port 4444 for telnet connections
>> Info : clock speed 2000 kHz
>>
>>
>>

>>
>> 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):

$ cat DEBUG
#!/bin/sh
#/Users/kuku/opt/xpack-openocd-0.10.0-14/bin/openocd -f /Users/kuku/opt/xpack-openocd-0.10.0-14/scripts/board/stm32f4discovery.cfg -c "gdb_port 3333" -c "telnet_port 4444"
/Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/bin/openocd -f /Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/scripts/board/stm32f4discovery.cfg -c "gdb_port 3333" -c "telnet_port 4444"
#/Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/bin/openocd -f /Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/scripts/board/st_nucleo_f4.cfg -c "gdb_port 3333" -c "telnet_port 4444"

[A. B. (Gast)]

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

[Christoph K. (chriskuku)]

$ /Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/bin/openocd -f /Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/scripts/board/stm32f4discovery.cfg -c "gdb_port 3333" -c "telnet_port 4444" -d3
xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2022-03-25-19:34)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
User : 3 3 options.c:63 configuration_output_handler(): debug_level: 3
User : 4 3 options.c:63 configuration_output_handler(): 
Debug: 5 3 options.c:244 add_default_dirs(): bindir=bin
Debug: 6 3 options.c:245 add_default_dirs(): pkgdatadir=
Debug: 7 3 options.c:246 add_default_dirs(): exepath=/Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/bin
Debug: 8 3 options.c:247 add_default_dirs(): bin2data=../
Debug: 9 3 configuration.c:44 add_script_search_dir(): adding /Users/kuku/Library/Preferences/org.openocd
Debug: 10 3 configuration.c:44 add_script_search_dir(): adding /Users/kuku/.config/openocd
Debug: 11 3 configuration.c:44 add_script_search_dir(): adding /Users/kuku/.openocd
Debug: 12 3 configuration.c:44 add_script_search_dir(): adding /Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/bin/..//site
Debug: 13 3 configuration.c:44 add_script_search_dir(): adding /Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/bin/..//scripts
Debug: 14 3 command.c:166 script_debug(): command - ocd_find /Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/scripts/board/stm32f4discovery.cfg
Debug: 15 3 configuration.c:99 find_file(): found /Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/scripts/board/stm32f4discovery.cfg
Debug: 16 3 command.c:166 script_debug(): command - ocd_find interface/stlink.cfg
Debug: 17 3 configuration.c:99 find_file(): found /Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/bin/..//scripts/interface/stlink.cfg
Debug: 18 3 command.c:166 script_debug(): command - adapter driver hla
Debug: 19 3 command.c:166 script_debug(): command - hla_layout stlink
Debug: 20 3 hla_interface.c:241 hl_interface_handle_layout_command(): hl_interface_handle_layout_command
Debug: 21 3 command.c:166 script_debug(): command - hla_device_desc ST-LINK
Debug: 22 3 hla_interface.c:228 hl_interface_handle_device_desc_command(): hl_interface_handle_device_desc_command
Debug: 23 3 command.c:166 script_debug(): command - hla_vid_pid 0x0483 0x3744 0x0483 0x3748 0x0483 0x374b 0x0483 0x374d 0x0483 0x374e 0x0483 0x374f 0x0483 0x3752 0x0483 0x3753 0x0483 0x3754
Debug: 24 3 command.c:166 script_debug(): command - transport select hla_swd
Debug: 25 3 hla_transport.c:202 hl_swd_transport_select(): hl_swd_transport_select
Debug: 26 3 command.c:166 script_debug(): command - ocd_find target/stm32f4x.cfg
Debug: 27 4 configuration.c:99 find_file(): found /Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/bin/..//scripts/target/stm32f4x.cfg
Debug: 28 4 command.c:166 script_debug(): command - ocd_find target/swj-dp.tcl
Debug: 29 4 configuration.c:99 find_file(): found /Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/bin/..//scripts/target/swj-dp.tcl
Debug: 30 4 command.c:166 script_debug(): command - transport select
Debug: 31 4 command.c:166 script_debug(): command - ocd_find mem_helper.tcl
Debug: 32 4 configuration.c:99 find_file(): found /Users/kuku/Library/xPacks/@xpack-dev-tools/openocd/0.11.0-4.1/.content/bin/..//scripts/mem_helper.tcl
Debug: 33 4 command.c:166 script_debug(): command - add_usage_text mrw address
Debug: 34 4 command.c:166 script_debug(): command - add_help_text mrw Returns value of word in memory.
Debug: 35 4 command.c:166 script_debug(): command - add_usage_text mrh address
Debug: 36 4 command.c:166 script_debug(): command - add_help_text mrh Returns value of halfword in memory.
Debug: 37 4 command.c:166 script_debug(): command - add_usage_text mrb address
Debug: 38 4 command.c:166 script_debug(): command - add_help_text mrb Returns value of byte in memory.
Debug: 39 4 command.c:166 script_debug(): command - add_usage_text mmw address setbits clearbits
Debug: 40 4 command.c:166 script_debug(): command - add_help_text mmw Modify word in memory. new_val = (old_val & ~clearbits) | setbits;
Debug: 41 4 command.c:166 script_debug(): command - transport select
Debug: 42 4 command.c:166 script_debug(): command - expr  [ string first "jtag" $_TRANSPORT ] != -1 
Debug: 43 4 command.c:166 script_debug(): command - transport select
Debug: 44 4 command.c:166 script_debug(): command - expr  [ string first "jtag" $_TRANSPORT ] != -1 
Debug: 45 4 command.c:166 script_debug(): command - transport select
Debug: 46 4 command.c:166 script_debug(): command - expr  [ string first "swd" $_TRANSPORT ] != -1 
Debug: 47 4 command.c:166 script_debug(): command - swd newdap stm32f4x cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x2ba01477
Debug: 48 4 hla_tcl.c:112 jim_hl_newtap_cmd(): Creating New Tap, Chip: stm32f4x, Tap: cpu, Dotted: stm32f4x.cpu, 8 params
Debug: 49 4 hla_tcl.c:123 jim_hl_newtap_cmd(): Processing option: -irlen
Debug: 50 4 hla_tcl.c:123 jim_hl_newtap_cmd(): Processing option: -ircapture
Debug: 51 4 hla_tcl.c:123 jim_hl_newtap_cmd(): Processing option: -irmask
Debug: 52 4 hla_tcl.c:123 jim_hl_newtap_cmd(): Processing option: -expected-id
Debug: 53 4 core.c:1468 jtag_tap_init(): Created Tap: stm32f4x.cpu @ abs position 0, irlen 0, capture: 0x0 mask: 0x0
Debug: 54 4 command.c:166 script_debug(): command - dap create stm32f4x.dap -chain-position stm32f4x.cpu
Debug: 55 4 command.c:166 script_debug(): command - tpiu create stm32f4x.tpiu -dap stm32f4x.dap -ap-num 0 -baseaddr 0xE0040000
Debug: 56 4 command.c:166 script_debug(): command - transport select
Debug: 57 4 command.c:166 script_debug(): command - expr  [ string first "jtag" $_TRANSPORT ] != -1 
Debug: 58 4 command.c:166 script_debug(): command - target create stm32f4x.cpu cortex_m -endian little -dap stm32f4x.dap
Info : 59 4 target.c:6188 target_create(): The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Debug: 60 4 hla_target.c:204 adapter_target_create(): adapter_target_create
Debug: 61 4 hla_target.c:174 adapter_init_arch_info(): adapter_init_arch_info
Debug: 62 4 command.c:300 register_command(): command 'rtt' is already registered
Debug: 63 4 command.c:300 register_command(): command 'tpiu' is already registered
Debug: 64 4 command.c:166 script_debug(): command - stm32f4x.cpu configure -work-area-phys 0x20000000 -work-area-size 0x10000 -work-area-backup 0
Debug: 65 4 target.c:2204 target_free_all_working_areas_restore(): freeing all working areas
Debug: 66 4 target.c:2204 target_free_all_working_areas_restore(): freeing all working areas
Debug: 67 4 target.c:2204 target_free_all_working_areas_restore(): freeing all working areas
Debug: 68 4 command.c:166 script_debug(): command - flash bank stm32f4x.flash stm32f2x 0 0 0 0 stm32f4x.cpu
Debug: 69 5 tcl.c:1316 handle_flash_bank_command(): 'stm32f2x' driver usage field missing
Debug: 70 5 command.c:166 script_debug(): command - flash bank stm32f4x.otp stm32f2x 0x1fff7800 0 0 0 stm32f4x.cpu
Debug: 71 5 command.c:300 register_command(): command 'stm32f2x' is already registered
Debug: 72 5 command.c:300 register_command(): command 'stm32f2x lock' is already registered
Debug: 73 5 command.c:300 register_command(): command 'stm32f2x unlock' is already registered
Debug: 74 5 command.c:300 register_command(): command 'stm32f2x mass_erase' is already registered
Debug: 75 5 command.c:300 register_command(): command 'stm32f2x options_read' is already registered
Debug: 76 5 command.c:300 register_command(): command 'stm32f2x options_write' is already registered
Debug: 77 5 command.c:300 register_command(): command 'stm32f2x optcr2_write' is already registered
Debug: 78 5 command.c:300 register_command(): command 'stm32f2x otp' is already registered
Debug: 79 5 tcl.c:1316 handle_flash_bank_command(): 'stm32f2x' driver usage field missing
Debug: 80 5 command.c:166 script_debug(): command - adapter speed 2000
Debug: 81 5 adapter.c:180 adapter_config_khz(): handle adapter khz
Debug: 82 5 adapter.c:144 adapter_khz_to_speed(): convert khz to adapter specific speed value
Debug: 83 5 adapter.c:144 adapter_khz_to_speed(): convert khz to adapter specific speed value
Debug: 84 5 command.c:166 script_debug(): command - adapter srst delay 100
Debug: 85 5 command.c:166 script_debug(): command - transport select
Debug: 86 5 command.c:166 script_debug(): command - expr  [ string first "jtag" $_TRANSPORT ] != -1 
Debug: 87 5 command.c:166 script_debug(): command - reset_config srst_nogate
Debug: 88 5 command.c:166 script_debug(): command - transport select
Debug: 89 5 command.c:166 script_debug(): command - expr  [ string first "hla" $_TRANSPORT ] != -1 
Debug: 90 5 command.c:166 script_debug(): command - stm32f4x.cpu configure -event examine-end 
  # Enable debug during low power modes (uses more power)
  # DBGMCU_CR |= DBG_STANDBY | DBG_STOP | DBG_SLEEP
  mmw 0xE0042004 0x00000007 0

  # Stop watchdog counters during halt
  # DBGMCU_APB1_FZ |= DBG_IWDG_STOP | DBG_WWDG_STOP
  mmw 0xE0042008 0x00001800 0

Debug: 91 5 command.c:166 script_debug(): command - stm32f4x.tpiu configure -event post-enable proc_post_enable stm32f4x
Debug: 92 5 command.c:166 script_debug(): command - stm32f4x.cpu configure -event reset-init 
  # Configure PLL to boost clock to HSI x 4 (64 MHz)
  mww 0x40023804 0x08012008   ;# RCC_PLLCFGR 16 Mhz /8 (M) * 128 (N) /4(P)
  mww 0x40023C00 0x00000102   ;# FLASH_ACR = PRFTBE | 2(Latency)
  mmw 0x40023800 0x01000000 0 ;# RCC_CR |= PLLON
  sleep 10                    ;# Wait for PLL to lock
  mmw 0x40023808 0x00001000 0 ;# RCC_CFGR |= RCC_CFGR_PPRE1_DIV2
  mmw 0x40023808 0x00000002 0 ;# RCC_CFGR |= RCC_CFGR_SW_PLL

  # Boost JTAG frequency
  adapter speed 8000

Debug: 93 5 command.c:166 script_debug(): command - stm32f4x.cpu configure -event reset-start 
  # Reduce speed since CPU speed will slow down to 16MHz with the reset
  adapter speed 2000

Debug: 94 5 command.c:166 script_debug(): command - reset_config srst_only
User : 95 5 options.c:63 configuration_output_handler(): srst_only separate srst_nogate srst_open_drain connect_deassert_srst
User : 96 5 options.c:63 configuration_output_handler(): 
Debug: 97 5 command.c:166 script_debug(): command - gdb_port 3333
Debug: 98 5 command.c:166 script_debug(): command - telnet_port 4444
Info : 99 5 server.c:308 add_service(): Listening on port 6666 for tcl connections
Info : 100 5 server.c:308 add_service(): Listening on port 4444 for telnet connections
Debug: 101 5 command.c:166 script_debug(): command - init
Debug: 102 5 command.c:166 script_debug(): command - target init
Debug: 103 5 command.c:166 script_debug(): command - target names
Debug: 104 5 command.c:166 script_debug(): command - stm32f4x.cpu cget -event gdb-flash-erase-start
Debug: 105 5 command.c:166 script_debug(): command - stm32f4x.cpu configure -event gdb-flash-erase-start reset init
Debug: 106 5 command.c:166 script_debug(): command - stm32f4x.cpu cget -event gdb-flash-write-end
Debug: 107 5 command.c:166 script_debug(): command - stm32f4x.cpu configure -event gdb-flash-write-end reset halt
Debug: 108 5 command.c:166 script_debug(): command - stm32f4x.cpu cget -event gdb-attach
Debug: 109 5 command.c:166 script_debug(): command - stm32f4x.cpu configure -event gdb-attach halt 1000
Debug: 110 5 target.c:1661 handle_target_init_command(): Initializing targets...
Debug: 111 5 hla_target.c:194 adapter_init_target(): adapter_init_target
Debug: 112 5 semihosting_common.c:115 semihosting_common_init():  
Debug: 113 5 hla_interface.c:122 hl_interface_init(): hl_interface_init
Debug: 114 5 hla_layout.c:95 hl_layout_init(): hl_layout_init
Debug: 115 5 adapter.c:144 adapter_khz_to_speed(): convert khz to adapter specific speed value
Debug: 116 5 adapter.c:148 adapter_khz_to_speed(): have adapter set up
Debug: 117 5 adapter.c:144 adapter_khz_to_speed(): convert khz to adapter specific speed value
Debug: 118 5 adapter.c:148 adapter_khz_to_speed(): have adapter set up
Info : 119 5 adapter.c:108 adapter_init(): clock speed 2000 kHz
Debug: 120 5 openocd.c:159 handle_init_command(): Debug Adapter init complete
Debug: 121 5 command.c:166 script_debug(): command - transport init
Debug: 122 5 transport.c:230 handle_transport_init(): handle_transport_init
Debug: 123 5 hla_transport.c:154 hl_transport_init(): hl_transport_init
Debug: 124 5 hla_transport.c:171 hl_transport_init(): current transport hla_swd
Debug: 125 5 hla_interface.c:55 hl_interface_open(): hl_interface_open
Debug: 126 5 hla_layout.c:40 hl_layout_open(): hl_layout_open
Debug: 127 5 stlink_usb.c:3697 stlink_open(): stlink_open
Debug: 128 5 stlink_usb.c:3709 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3744 serial: 
Debug: 129 5 stlink_usb.c:3709 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3748 serial: 
Debug: 130 5 stlink_usb.c:3709 stlink_open(): transport: 4 vid: 0x0483 pid: 0x374b serial: 
Debug: 131 5 stlink_usb.c:3709 stlink_open(): transport: 4 vid: 0x0483 pid: 0x374d serial: 
Debug: 132 5 stlink_usb.c:3709 stlink_open(): transport: 4 vid: 0x0483 pid: 0x374e serial: 
Debug: 133 5 stlink_usb.c:3709 stlink_open(): transport: 4 vid: 0x0483 pid: 0x374f serial: 
Debug: 134 5 stlink_usb.c:3709 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3752 serial: 
Debug: 135 5 stlink_usb.c:3709 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3753 serial: 
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
User : 143 7047 command.c:619 command_run_line(): 
Debug: 144 7047 target.c:2204 target_free_all_working_areas_restore(): freeing all working areas
Debug: 145 7047 hla_interface.c:130 hl_interface_quit(): hl_interface_quit
$

[A. B. (Gast)]

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.

[Stefan F. (Gast)]

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.

[Christoph K. (chriskuku)]

$ 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.

[Christoph K. (chriskuku)]

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.

[A. B. (Gast)]

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.

[Christoph K. (chriskuku)]

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:

crw-rw-rw-  1 root   wheel     20,  10  2 Apr 09:22 io8logtemp
crw-rw-rw-  1 root   wheel     22,   8  2 Apr 09:23 tty.usbmodem14203
crw-r-----  1 root   operator   1,  11  2 Apr 09:23 rdisk2
brw-r-----  1 root   operator   1,  11  2 Apr 09:23 disk2
crw-rw-rw-  1 root   wheel     22,   9  2 Apr 09:23 cu.usbmodem14203
crw-rw-rw-  1 root   wheel      3,   2  2 Apr 09:23 null
crw-rw-rw-  1 root   tty       15,   3  2 Apr 09:23 ptmx
crw--w----  1 kuku   tty       16,   2  2 Apr 09:23 ttys002
$

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

[Stefan F. (Gast)]

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

[Christoph K. (chriskuku)]

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.

[A. B. (Gast)]

Christoph K. schrieb:
>

> crw-rw-rw-  1 root   wheel     20,  10  2 Apr 09:22 io8logtemp
> crw-rw-rw-  1 root   wheel     22,   8  2 Apr 09:23 tty.usbmodem14203
> crw-r-----  1 root   operator   1,  11  2 Apr 09:23 rdisk2
> brw-r-----  1 root   operator   1,  11  2 Apr 09:23 disk2
> crw-rw-rw-  1 root   wheel     22,   9  2 Apr 09:23 cu.usbmodem14203
> crw-rw-rw-  1 root   wheel      3,   2  2 Apr 09:23 null
> crw-rw-rw-  1 root   tty       15,   3  2 Apr 09:23 ptmx
> crw--w----  1 kuku   tty       16,   2  2 Apr 09:23 ttys002
> $
>

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.

[Christoph K. (chriskuku)]

A. B. schrieb:
> Christoph K. schrieb:
>>

>> crw-rw-rw-  1 root   wheel     20,  10  2 Apr 09:22 io8logtemp
>> crw-rw-rw-  1 root   wheel     22,   8  2 Apr 09:23 tty.usbmodem14203
>> crw-r-----  1 root   operator   1,  11  2 Apr 09:23 rdisk2
>> brw-r-----  1 root   operator   1,  11  2 Apr 09:23 disk2
>> crw-rw-rw-  1 root   wheel     22,   9  2 Apr 09:23 cu.usbmodem14203
>> crw-rw-rw-  1 root   wheel      3,   2  2 Apr 09:23 null
>> crw-rw-rw-  1 root   tty       15,   3  2 Apr 09:23 ptmx
>> crw--w----  1 kuku   tty       16,   2  2 Apr 09:23 ttys002
>> $
>>

>
> 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.

[A. B. (Gast)]

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)

[Christoph K. (chriskuku)]

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.

[Christoph K. (chriskuku)]

Wenn eine shared lib fehlte, so würde das gemeldet. ldd gibt‘s unter 
macOS nicht.

[Christoph K. (chriskuku)]

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:

kuku@kuku-Lenovo-Y70-70-Touch:~/stm32/stlink/bin$ ./st-info --probe
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:    V2J34S25
  serial:     066CFF485153826687123124
  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

Nun am Mac:

$ ./st-info --probe
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:    V2J34S25
  serial:     066CFF485153826687123124
  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

Soweit wird also die Target MCU erkannt.

Jetzt das DIY-MORE Board angeschlossen an SWD:

$ ./st-info --probe
Failed to parse flash type or unrecognized flash type
setting new configuration (0 -> 1)
Failed to enter SWD mode
Found 1 stlink programmers
  version:    V2J34S25
  serial:     066CFF485153826687123124
  flash:      0 (pagesize: 0)
  sram:       0
  chipid:     0x000

detected chip_id parametres

# Device Type: unknown
# Reference Manual: RM0000
#
chip_id 0x0
flash_type 0
flash_size_reg 0x0
flash_pagesize 0x0
sram_size 0x0
bootrom_base 0x0
bootrom_size 0x0
option_base 0x0
option_size 0x0
flags 0

  dev-type:   unknown
$ 
$

Linux:
kuku@kuku-Lenovo-Y70-70-Touch:~/stm32/stlink/bin$ ./st-info --probe
Failed to parse flash type or unrecognized flash type
Failed to enter SWD mode
Found 1 stlink programmers
  version:    V2J34S25
  serial:     066CFF485153826687123124
  flash:      0 (pagesize: 0)
  sram:       0
  chipid:     0x000

detected chip_id parametres

# Device Type: unknown
# Reference Manual: RM0000
#
chip_id 0x0
flash_type 0
flash_size_reg 0x0
flash_pagesize 0x0
sram_size 0x0
bootrom_base 0x0
bootrom_size 0x0
option_base 0x0
option_size 0x0
flags 0

  dev-type:   unknown

[A. B. (Gast)]

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 ...

[Christoph K. (chriskuku)]

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.

[A. B. (Gast)]

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.

[Christoph K. (chriskuku)]

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.

[Bauform B. (bauformb)]

Christoph K. schrieb:
> Könnte es sein, daß das Target so programmiert ist,
> daß die PA14/PA13 nicht auf SWDCLK/SWDIO reagieren?

Ja.

[Christoph K. (chriskuku)]

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?

[A. B. (Gast)]

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.

[Stefan F. (Gast)]

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).

[Christoph K. (chriskuku)]

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)

[Stefan F. (Gast)]

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.

[A. B. (Gast)]

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.

[Christoph K. (chriskuku)]

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.

$ ./st-info --probe
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:    V2J39S27
  serial:     0670FF505252836687072821
  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
$

3. openocd meldet allerdings:

xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2022-03-25-19:34)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
Info : STLINK V2J39M27 (API v2) VID:PID 0483:374B
Info : Target voltage: 2.905338
Info : [stm32f4x.cpu] Cortex-M4 r0p1 processor detected
Info : [stm32f4x.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 3333
Info : Listening on port 3333 for gdb connections

Und ich bekomme folgenden Fehler:

GNU gdb (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.50.20181213-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
0x5bb3b9be in ?? ()
.gdbinit:4: Error in sourced command file:
Error erasing flash with vFlashErase packet
(gdb) 


.gdbinit sieht so aus:
file myblinky_hse_pll_168_DIYMORE.elf
set mem inaccessible-by-default off
tar remote :3333
load

[Christoph K. (chriskuku)]

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.

[Stefan F. (Gast)]

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

[Christoph K. (chriskuku)]

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

      while (1)
      {
        /* USER CODE BEGIN 3 */
       pin_state = !pin_state;
       HAL_GPIO_WritePin(Led2_GPIO_Port, Led2_Pin, pin_state);
       // synchronous delay for 500 ms
       HAL_Delay(100);
       ITM_SendString("LED\n");
      }

eingebaut und dann die Funktion ITM_SendString(*str) implementiert.

void ITM_SendString(char *str)
{
  while(*str){
    ITM_SendChar(*str);
    str++;
  }
}

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.

[Klaus W. (mfgkw)]

Machst du C oder C++?
Bei C++ könnte es zwei verschiedene ITM_SendString geben (für const und 
nicht-const).

[Stefan F. (Gast)]

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?

[Christoph K. (chriskuku)]

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.

[Stefan F. (Gast)]

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.

[Christoph K. (chriskuku)]

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.

[Klaus W. (mfgkw)]

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.

[Klaus W. (mfgkw)]

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.

[Stefan F. (Gast)]

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!

[Stefan F. (Gast)]

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.

[Christoph K. (chriskuku)]

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.

[Stefan F. (Gast)]

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"

[Christoph K. (chriskuku)]

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.

int main(void)
{
  /* USER CODE BEGIN 1 */
  int count=0;
  static char buf[32];

  /* USER CODE END 1 */

  /* MCU Configuration--------------------------------------------------------*/

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();

  /* USER CODE BEGIN Init */

  /* USER CODE END Init */

  /* Configure the system clock */
  SystemClock_Config();

  /* USER CODE BEGIN SysInit */

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_USART3_UART_Init();



    volatile static unsigned short pin_state = 0;
    /* Infinite loop */
     /* USER CODE BEGIN WHILE */

      while (1)
      {
        /* USER CODE BEGIN 3 */
       pin_state = !pin_state;
       HAL_GPIO_WritePin(Led2_GPIO_Port, Led2_Pin, pin_state);
       // synchronous delay for 500 ms
       HAL_Delay(500);
       if(count++ % 10 == 0)
            sprintf(buf,"count=%d\n",count),ITM_SendString(buf);
      }
      /* USER CODE END WHILE */

}

void ITM_SendString(char *str)
{
  while(*str){
    ITM_SendChar(*str++);
  }
}

Trotz dieser relativ niedrigen Rate von Meldungen kriege ich einen 
Tracebuffer Überlauf im CudeIDE (s. Bild).

[Stefan F. (Gast)]

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.

[Christoph K. (chriskuku)]

(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 :)

[Stefan F. (Gast)]

Christoph K. schrieb:
> Das ist doch schon eine ganze Menge für so ein paar Meldungen.

Ja, das entspricht etwa 1/2 Bibel.

[Christoph K. (chriskuku)]

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.

[Christoph K. (chriskuku)]

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. (chriskuku)]

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.

[Stefan F. (Gast)]

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.