Run/Debug problem in SW4STM32 using ST-Link/V2 SWD

mostafanfs · ‎2015-10-30

Posted on October 31, 2015 at 07:46

I've just started using SW4STM32 and wrote a sample project to check it out but after setting up my board and its connection and a Run/Debug configuration I got this error when I want to deploy my program using ST-Link/V2 SWD:

Open On-Chip Debugger 0.9.0-dev-00415-g2d4ae3f-dirty (2015-06-12-17:54)

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

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 : clock speed 950 kHz

Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748

Info : using stlink api v2

Info : Target voltage: 3.261335

Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

Error: timed out while waiting for target halted

TARGET: stm32f1x.cpu - Not halted

in procedure 'program'

in procedure 'reset' called at file ''embedded:startup.tcl'', line 478

in procedure 'ocd_bouncer'

Unable to reset target **

shutdown command invoked

Isn't this supposed to work without problems?

I can program and debug the chip using every other tools I have on my computer like Keil, Atollic TrueSTUDIO and STM32 ST-LINK Utility pretty easy and I wasn't expecting any problems at this stage!

ST-LINK has the latest firmware and I have installed the latest ST-LINK USB driver so I sort of blame SW4STM32 or maybe STM32CubeMX because the project was created using STM32CubeMX.

Any thoughts?

markb · ‎2015-10-31

Posted on October 31, 2015 at 12:19

Hi,

I am using openocd to program an STM32F405 and it works like a charm (on Linux, of course).

I don't specify the reset behaviour and openocd just reports ''none separate'':

Open On-Chip Debugger 0.9.0 (2015-05-22-21:08)

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: 2000 kHz

adapter_nsrst_delay: 100

none separate

Info : Unable to match requested speed 2000 kHz, using 1800 kHz

Info : clock speed 1800 kHz

Info : STLINK v2 JTAG v16 API v2 SWIM v4 VID 0x0483 PID 0x3748

Info : using stlink api v2

Info : Target voltage: 3.226178

Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x01000000 pc: 0x0801e208 msp: 0x20020000

target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x01000000 pc: 0x0801e208 msp: 0x20020000

auto erase enabled

Info : device id = 0x10016413

Info : flash size = 1024kbytes

Info : Padding image section 0 with 24 bytes

target state: halted

target halted due to breakpoint, current mode: Thread

xPSR: 0x61000000 pc: 0x20000042 msp: 0x20020000

wrote 393216 bytes from file pb4.hex in 14.059049s (27.313 KiB/s)

target state: halted

target halted due to breakpoint, current mode: Thread

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20020000

target state: halted

target halted due to breakpoint, current mode: Thread

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20020000

verified 283252 bytes in 2.643463s (104.641 KiB/s)

shutdown command invoked

The programing is done by:

source [find interface/stlink-v2.cfg]

transport select hla_swd

source [find target/stm32f4x.cfg]

proc mb_flash {IMGFILE} {

reset init

flash write_image erase $IMGFILE

catch { verify_image $IMGFILE }

reset run

shutdown

}

I hope this helps.

Cheers,

Mark

mostafanfs · ‎2015-10-31

Posted on October 31, 2015 at 15:40

Thank you

Just a question. What are those last lines? Is that some sort of script? It that is the case then where should I put them in project settings?

markb · ‎2015-10-31

Posted on October 31, 2015 at 18:30

Hi,

Those last lines are (a part of) the contents of openocd.cfg and I am calling openocd (from a Makefile) like this:

openocd -f openocd.cfg -c ''mb_flash pb4.hex''

Cheers,

Mark

mostafanfs · ‎2015-11-01

Posted on November 01, 2015 at 09:41

Thank you. Well I already have these settings :

Yet I can only do the debugging but still can not Run/upload applications on the board.

Then I don't know what the problem is. I'm using ST-LinkV2 and SWD connection. Simple as that. And I only have this problem with SW4STM32. I mean take Atollic TrueSTUDIO as an example which I'm fine with it by the way. Doesn't it use OpenOCD?

-----------------------------------------

Besides even if I select ''Use local script'' instead of ''Manual spec'' in Debug Configurations, there is one .cfg file in my project with contents as this:

# This is an Mosi_STM32F103RCT board with a single STM32F103RCTx chip.

# Generated by System Workbench for STM32

source [find interface/stlink-v2.cfg]

set WORKAREASIZE 0xC000

transport select ''hla_swd''

source [find target/stm32f1x_stlink.cfg]

# use hardware reset, connect under reset

reset_config srst_only srst_nogate

Which is not the same as your script for the most part. And it's pretty obvious that the SW4STM32 itself has generated this script based on my settings.

So I don't think I'm supposed to modify anything.

What do you guys think?

markb · ‎2015-11-01

Posted on November 01, 2015 at 10:54

Hi,

Your script says:

# use hardware reset, connect under reset

reset_config srst_only srst_nogate

I don't do that and in the past, when I tried similar configs, it always gave problems. YMMV.

Cheers,

Mark

mostafanfs · ‎2015-11-01

Posted on November 01, 2015 at 12:18

Thank you.

Yes I was just looking in another thread in openstm32 and figured ''srst_only'' is making problems. So I selected ''Use local script'' and gave the path of my script.

Now apparently I can debug without any problem but I still can not Run the application!

I don't know how they are different. Here is the console log when I hit Run.

***********************************

Open On-Chip Debugger 0.9.0-dev-00418-g9afb8b4-dirty (2015-09-28-12:09)

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

none separate

Info : Unable to match requested speed 1000 kHz, using 950 kHz

Info : clock speed 950 kHz

Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748

Info : using stlink api v2

Info : Target voltage: 3.263492

Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x01000000 pc: 0x08002cd8 msp: 0x2000c000

** Programming Started **

auto erase enabled

Error: Invalid command argument

image.base_address option value ('Configuration.elf') is not valid

** Programming Failed **

shutdown command invoked

***********************************

And here is the last line in script: (I should mention again that Debug is working with this script)

# use hardware reset, connect under reset

reset_config srst_nogate

rharias · ‎2016-01-07

Posted on January 07, 2016 at 17:05

I had this same problem:

................

image.base_address option value ('Configuration.elf') is not valid

................

and that file was .elf not should be spaces.

To configure the file name .elf:

Propierties-> C / C ++ build-> setting-> Buid artifact-> Artifact name-> ''name.elf''

zootroop · ‎2016-02-06

Posted on February 06, 2016 at 23:53

Hey Mustafanfs,

Rename the elf file. That is to say remove the 'Configuration' part of it. It worked for me.

Imagine, the folks who developed CubeMX didn't expect that error to happen LOL!

I know how insulting IDE's can be, especially eclipse is one that can rise one's temper. Did you know that eclipse doesn't look into its own created project tree for compiling resources. No, you have to tell it to look there via Built settings => compiler includes. Insane, not? Instead this being the fact by default. Amazingly ridiculous. And that's not the only nonsensical stuff there is about eclipse. It's really unbelievable how 'smart' one must be to understand today's crooked logic in the ICT world. There have been better days some 25 years ago.

Good luck!