Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32

Forum List Topic List

You are viewing a reply to Target connection fails with "Cannot identify target as a stm32x" (although STM32L053 works)  

Target connection fails with "Cannot identify target as a stm32x" (although STM32L053 works)

Posted by Coffeebean on 2017-01-03 15:28

Hi there,

I’ve been quite busy in private matters and had no time to get any further with my STM32 problem until today.
However, at first, thanks for all your answers!

@LaurentL:
I’ve updated five minutes ago my System Workbench installation to v1.12 and the problem still exists unchanged.
I investigated the incorrect read target voltage a bit:
It’s also misread when using the Nucleo STM32 debugger along with the Nucleo board (STM32L053).
I’ve measured on both the Nucleo board and my custom board the voltages between GND and 3.3V target voltage conector on side of the debugger, both times it’s around 3.3 VDC (3.31 - 3.35V), so as it seems, this is clearly misread by OpenOCD.
But I don’t suspect this to be the cause for my ‘signature problem’, as like already mentioned, flashing and debugging the Nucleo board works.

@kfishy:
Yes, I tried that, flashing both my custom board and the original nucleo board works using the ST-Link Utility.

@Vetch:
Thanks for your suggestion.
I’ve had the debugger connected to a passive USB 2.0 hub, connected to a USB 2.0 port.
However, neither updating the drivers under windows, nor connecting the debugger directly to a USB2 or one of the (Intel) USB 3.0 ports did change anything.

Propably I did some mistake when building up my prototype board?
I’ve added below two pictures of the schematic and the bread board setup.
Please note I’ve used for this first basic setup a bread board adapter for the QFP48 package.
I also double checked that every connection you see on the schematic is correct on the board (the airwires left to route in eagle are connected using straight wires).

The connectors JP6 and JP1 can be ignored,as they aren’t connected at the moment.
JP1 was connected to the Nucleo board debugger as follows:
JP1-1 -> Debugger-1
JP1-2 -> Debugger-2
JP1-3 -> Debugger-4
JP1-4 -> Debugger-5
JP1-5 -> Debugger-3

Link to board imageQuestion
Link to schematic imageQuestion
Link to zipped eagle filesQuestion

Output from latest target flashing trial:

14:39:03 **** Programing project stm32f0_blinky on chip ****
/home/markus/Ac6/SystemWorkbench/plugins/fr.ac6.mcu.externaltools.openocd.linux64_1.12.0.201611241417/tools/openocd/bin/openocd -f stm32f0_blinky.cfg -s /home/markus/Projekte/stm32f0_blinky/stm32f0_blinky/SW4STM32/stm32f0_blinky -s /home/markus/Ac6/SystemWorkbench/plugins/fr.ac6.mcu.debug_1.11.2.201612060912/resources/openocd/scripts -c “program Debug/stm32f0_blinky.elf verify reset exit”
Open On-Chip Debugger 0.10.0-dev-00273-g394abef (2016-11-24-15:12)
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
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_assert_srst
srst_only separate srst_nogate srst_open_drain connect_assert_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 M v15 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 0.012648
Error: target voltage may be too low for reliable debugging
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
adapter speed: 950 kHz
stm32f0x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc
in procedure ‘program’
in procedure ‘reset’ called at file “embedded:startup.tcl”, line 478
in procedure ‘ocd_bouncer’
in procedure ‘ocd_process_reset’
in procedure ‘ocd_process_reset_inner’ called at file “embedded:startup.tcl”, line 248
in procedure ‘stm32f0x.cpu’ called at file “embedded:startup.tcl”, line 370
in procedure ‘ocd_bouncer’

    • Programming Started **

auto erase enabled
Error: Cannot identify target as a stm32x
Error: auto_probe failed

    • Programming Failed **

shutdown command invoked


14:39:03 Build Finished (took 142ms)

A little footnote:
This last trial of flashing was done under my linux system, but the result is the same under my windows installation.

Reads: 9083
Link
Posted by LaurentL on 2017-01-03 18:31

Hello,

About the log text, i can see you’re using the menu Target => Erase or Program, why don’t you use the debug button ?

For the Nucleo used as a Nucleo, it should give you the vdd voltage.
Do you have the CN2 ON for Nucleo usage.
JP6 ON mandatory to have VDD on target cpu.
JP5 on U5V (not E5V).


For the schematic, i would connect VSSA to GND and VDDA to VDD.
I would remove the resistor of 1K pull-up on Reset (STM32 has an internal reset of 50K i think) or change value to 10K at least.
For the SWD connections, can you tell which one you made ?
STlink CN4 has 6 pins:
Pin 1 is STlink VDD input to measure : To connect to your VDD at 3.3V
Pin 2 is SWCLK
Pin 3 is GND
Pin 4 is SWDIO
Pin 5 is N_Reset
Pin 6 is SWO (not needed for debug)

Then, you should have removed the 2 Jumpers on CN2 for STLink usage.
Maybe remove JP6 to not have VDD on MCU on Nucleo.

Rgds,
Laurent

Link
Posted by Coffeebean on 2017-01-04 13:22

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

Link

Posted by LaurentL on 2017-01-04 15:34

Hello,

You should use the Debug button but prior that you have to use menu “Debug as” => “AC6 C/C++ Application”.
After a correct debugging session, whenever you hit the debug button, it will debug the last debugged appli so it can be the wrong one.
You can select the appli to debug with the little arrow next to the debug button or wait over the button and see which appli will be debugged with the tooltip name.
ame.
Then, when you say the gdb console window is cleared and you see only the text of gdb, you have to switch to the openocd console to see the log.
There is a button on the rigth side of console window to switch window and choose the openocd one.


For the verbose mode of openocd, yes there is one, use the -d arg in openocd options text input in Debugger options tab in debug config window.
You’ll see a lot more text in openocd window and you might see which id it reads.
But there might be a lot of lines so you might have to remove the console buffer limit:
Go to menu Window => Preferences and Run/debug => Console and untick “Limit console output” and tick the 2 “show when program writes to standard out (and error)”.

For the connections, it seems they’re correct. Except VDDA, connect it to VDD or it is a typo ?
When you says “The Nucleo ST-Link Debugger is completely disconnected”, do you have broken the board ?
If yes, when you debug the nucleo L0, where do you connect the power ?
You take the 5V usb from dongle (where) and connect it to Vin (CN7-24) ?
So, no jumper at all on STlink side.

Another check is the script config file for openocd (cfg file), you should have created one with your custom board.
You should have a cfg file named with the project name on the bottom files of project in project explorer view.
Can you tell us which info are inside ?
You should have a swd transport selected to work (not JTAG that requires more pin and is not available on CortexM0 (STM32F0 or L0)).
And can you check in your “debug config” window in Debugger tab that this cfg filename is selected and “use local script” button is selected.

The cfg you made should contain these lines:
source find interface/stlink-v2-1.cfg
set WORKAREASIZE 0x2000
source find target/stm32f0x_stlink.cfg

Rgds,
Laurent

Link
Posted by Coffeebean on 2017-01-04 17:21

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

stm32f0_blinky.cfg (335 b)
Link
Posted by Coffeebean on 2017-01-04 17:39

Update:
It doesn’t seem to be that easy, I’m afraid.
I just replaced (and afterwards, of course, reverted that) the stm32f0x.cfg and stm32f0x_stlink.cfg files within the System Workbench folder (~/Ac6/SystemWorkbench/plugins/fr.ac6.mcu.debug_1.11.2.201612060912/resources/openocd/scripts/target/) by them I downloaded from http://gnuarmeclipse.github.io/debug/openocd/Question , now the reset doesn’t seem to work:
pastebin outputQuestion .
I don’t have a clue what I could try now :/

(also added hereQuestion the terminal output of a working OpenOCD session with the downloaded binaries, along with my custom board configuration file for comparison).

Link
Posted by LaurentL on 2017-01-04 18:32

No, you should not replace files, they are ok.

The error you get in both config is when it tries to start the PLL to be faster.

So, it is weird, either there is an error on PLL register (i checked on F030 Ref Manual, it is ok) or there is a mistake on analog part of schematic ? (VSSA & VDDA to check)
There is no VREF nor Vbat pin.

Or the Reset is not released ?
Can you check with an osciloscope the reset signal ?

I checked on a Nucleo F030, it is ok, the PLL doesn’t fail and debugging is ok.

Or is it the clone that has an issue, can you try with the stlink (normally, stlink V2 or V2-1 is no more an issue for cfg).

Regards,
Laurent

Link
Posted by Coffeebean on 2017-01-04 21:03

Okay, here’s what I did:

In the meantime, I tried to replace the binarys of OpenOCD and the config files with each other, which lead everytime to a working setup outside of System Workbench.
(Of course, I reverted it all back).
So, the config files can’t be the (only) cause for my problem.

I switched back to the original Nucleo ST-Link debugger (and edited the config file stm32f0_blinky.cfg entry back from interface/stlink-v2.cfg to interface/stlink-v2-1.cfg).
Still, the result is the same (sidenode: It’s reproducable that the original ST-Link seems to be unable to read the target voltage successful, perhaps this is a hint? Measured the voltage on debugger-side again, so the connection is ok).

Also, I rechecked the VSSA (tied to GND) and VDDA (tied to 3.3 V) connections aaaand bingo:
(I’m a little bit embarressed to write it here as an electrical engineer)
I had a cold soldering point at the VDDA connection.
Somehow, now I’m able to establish a stable debug session with the original ST-Link and the cloned one, as well.

I still don’t get and am really interested in the answer, why a missing power supply for the ADC can lead to a flashable board using the ST-Link Utility, but not with the System Workbench toolchain?
To be honest I don’t trust the board an inch at the moment and will play with it around a little bit more, but it seems it’s now working :-)
Thanks a lot for the moment to everyone who wrote here and tried to help, especially LaurentL! biggrin

Link

Posted by LaurentL on 2017-01-05 16:13

Hello, glad to hear you succeeded.

The answer is simple, VSSA and VDDA are the Analog supply so it is not only the ADC that needs it, PLL is analog too, and maybe other parts needs it.

And for STlink Utility, it means they don’t activate the PLL to be faster so it is working without the Analog supply.

Rgds,
Laurent

Link
Posted by Coffeebean on 2017-01-08 15:14

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

Link