Hi there,

about your first question:
When using the debug symbol (the little bug), the console output gets reset and just the output of the gdb call is left
(GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160616-cvs
Copyright (C) 2015 Free Software Foundation, Inc. ... ).
Due to this, I’m using the Target->Erase/Program commands to avoid this (abnormal behaviour?).

The Nucleo ST-Link Debugger is completely disconnected from the Nucleo board itself and therefore, the Nucleo board gets it’s power supply externally (so, JP5 is set to E5V).
All the other jumpers on the ST-Link / Nucleo board are setted as you described.

About my circuit:
I removed the external pull-up (I’m used to this by working e.g. with the AVRs), no change.
I also just connected vSSA and VDDA to GND.
The SWD connections I already described by the JP1 (on my board) to the debugger connections, so the connections i made are like:

Nucleo ST-Link Debugger -> Custom board:
(1) VDD_TARGET -> JP1-1 (3.3V)
(2) SWCLK -> JP1-2 (SWCLK)
(3) GND -> JP1-5 (GND)
(4) SWDIO -> JP1-3 (SWDIO)
(5) NRST -> JP1-4 (NRST)
Result: Doesn’t work with mentioned error message (Cannot identify target bla bla).

Nucleo ST-Link Debugger -> Nucleo board with STM32L053:
(1) VDD_TARGET -> CN7-16 (3.3V)
(2) SWCLK -> CN7-15 (SWCLK)
(3) GND -> CN7-19 (GND)
(4) SWDIO -> CN7-13 (SWDIO)
(5) NRST -> CN7-14 (NRST)
Result: Works flawless, debugging, flashing, setting and removing breakpoints et cetera.

I’m also almost certain now, that it has nothing to do in special with the Nucleo ST-Link Debugger, as I borrowed one of these little chinese ST-Link clones from a work colleague (ebay-link, it looks like this ) and the same thing happens with this one.
Following up the connections I made with this second debugger:

Clone ST-Link Debugger -> Custom board:
(1) T_JRST -> JP1-4 (NRST)
(2) 3.3V -> JP1-1 (3.3V)
(4) T_SWCLK -> JP1-2 (SWCLK)
(6) T_SWDIO -> JP1-3 (SWDIO)
(7) GND -> JP1-5 (GND)
Result: Doesn’t work with mentioned error message (Cannot identify target bla bla).

Clone ST-Link Debugger -> Nucleo board with STM32L053:
(1) T_JRST -> CN7-14 (NRST)
(2) 3.3V -> CN7-16 (3.3V)
(4) T_SWCLK -> CN7-15 (SWCLK)
(6) T_SWDIO -> CN7-13 (SWDIO)
(7) GND -> CN7-19 (GND)
Result: Works flawless, debugging, flashing, setting and removing breakpoints et cetera.

The interesting thing is, all four (!!) mentioned scenarios are able to flash the Nucleo board and my custom board, as well, using the ST-Link Utility.

About this strange error message:
Is there a possibility (e.g. a kind of -verbose switch to enable or similar) to get the information, which signature was read from my custom board, to compare it with the read signature by the ST-Link Utility?

Best regards,
Markus

Hi there,

thanks for the tip about the debug window, I’m now able to find the OpenOCD output, but it’s the same as when doing it the way over Target=>Program, so still no change.

Interesting fact seems to be, I’ve used the project-dependend .cfg-file (appended to this reply) which was created by CubeMX I think.
This file seems to be correct, as I’m able to use the ‘vanilla’, SystemWorkbench-independent OpenOCD (from here) to connect, and this seems to work:

markus@markusPC ..se/openocd/0.10.0-201610281609-dev/bin % ./openocd -f /tmp/stm32f0_blinky.cfg
GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-dev-00498-gbbfb673 (2016-10-28-17:01)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: target/stm32f0x_stlink.cfg is deprecated, please switch to target/stm32f0x.cfg
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v27 API v2 SWIM v6 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.567957
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints

Please note I used the clone ST-Link debugger, and therefore changed the settings from stlink-v2-1 to stlink-v2.

As far as I understand this configuration files, my problem may is caused by one of the included configuration files, either interface/stlink-v2.cfg or target/stm32f0x_stlink.cfg.
I highly doubt there’s a problem in the debugger configuration file, as this works with the nucleo board.
stm32f0x_stlink.cfg links in my downloaded version straight to target/stm32f0x.cfg, the SW-version differs a bit:

markus@markusPC ..0.10.0-201610281609-dev/scripts/target % diff stm32f0x_stlink.cfg /home/markus/Ac6/SystemWorkbench/plugins/fr.ac6.mcu.debug_1.11.2.201612060912/resources/openocd/scripts/target/stm32f0x_stlink.cfg -uNr

---

+++ /home/markus/Ac6/SystemWorkbench/plugins/fr.ac6.mcu.debug_1.11.2.201612060912/resources/openocd/scripts/target/stm32f0x_stlink.cfg 2016-11-24 04:48:56.000000000 +0100

@@ -1,2 +1,11 @@
-echo “WARNING: target/stm32f0x_stlink.cfg is deprecated, please switch to target/stm32f0x.cfg”

+if { info exists TRANSPORT } { + if { $TRANSPORT == “hla_jtag”} { + transport select “hla_jtag” + } + + if { $TRANSPORT == “hla_swd”} { + transport select “hla_swd” + } +} +

source find target/stm32f0x.cfg

Also, I compared the stm32f0x.cfg files, these differ even more:

markus@markusPC ..0.10.0-201610281609-dev/scripts/target % diff stm32f0x.cfg /home/markus/Ac6/SystemWorkbench/plugins/fr.ac6.mcu.debug_1.11.2.201612060912/resources/openocd/scripts/target/stm32f0x.cfg -uNr

---

+++ /home/markus/Ac6/SystemWorkbench/plugins/fr.ac6.mcu.debug_1.11.2.201612060912/resources/openocd/scripts/target/stm32f0x.cfg 2016-11-24 04:48:56.000000000 +0100

@@ -47,7 +47,9 @@

adapter_nsrst_delay 100

-reset_config srst_nogate

+# use hardware reset, connect under reset +# connect_assert_srst needed if low power mode application running (WFI...) +reset_config srst_only srst_nogate connect_assert_srst

if {!using_hla} {
# if srst is not fitted use SYSRESETREQ to
@@ -61,6 +63,10 @@
}

proc stm32f0x_default_examine_end {} {

+ # Enable DBGMCU clock + # RCC_APB2ENR |= DBGMCUEN + mmw 0x40021018 0x00400000 0 +

# Enable debug during low power modes (uses more power)
mmw 0x40015804 0x00000006 0 ;# DBGMCU_CR |= DBG_STANDBY | DBG_STOP

@@ -80,7 +86,14 @@
adapter_khz 8000
}

+$_TARGETNAME configure -event gdb-attach { + # Needed to be able to use the connect_assert_srst in reset_config + # otherwise, can’t read device id + reset init +} +

# Default hooks
$_TARGETNAME configure -event examine-end { stm32f0x_default_examine_end }
$_TARGETNAME configure -event reset-start { stm32f0x_default_reset_start }
$_TARGETNAME configure -event reset-init { stm32f0x_default_reset_init }

+

Perhaps, my problem is caused by one of these differences?

About your questions and suggestions:
I uploaded to pastebin the OpenOCD-output with enabled -d switch.
To be honest, I have absolute no clue if this gives more information for finding my problem?

About my original (Nucleo-) ST-Link Debugger:
Yes, the boards are physically disconnected from each other, as my first intention was to include the debugger into the prototype I’m planing to build.
But as the target voltage readout seems to work using the Cloned ST-Link debugger from my colleague, I started to use that one at the moment now.
VDDA is connected straight to VDD, typo indeed.
When using the L0-board, I connect an external power supply to the E5V/GND connector on CN7 (and of course, set the jumper to E5V supply).

I rechecked the setting in the debug profile, indeed the correct file, stm32f0_blinky.cfg, is there selected and the option ‘Use local script’ is activated.

So in summary, basically one of the differences in either stm32f0x_stlink.cfg or stm32f0x.cfg should be responsible for my problem, or what do you think?

Thank you very much for your time and patience

Hi,

okay, didn’t thought that the STlink Utility handles the flash process in another way than OpenOCD, but it seems to.
Your description makes perfectly sense.

However, just as a little feedback, it’s still working like a charm, thanks a lot again!