[mcipjvw]

Thanks for the message and the OpenOCD 0.12.0 update. Works like a charm now with the stlink-v3pwr adapter.

BR Martin

 

[mcipjvw]

Hi,

It is working now. I repeated step 5 once again, but now I replaced all accompanied binaries of openocd.
Remains my last remark, that it should work out of the box. But I can go on! Waiting for new releases of openocd/visualgdb now.

Thx!

 

[mcipjvw]

Hi,

Thanks man! Sorry for the late response. Finally I found some time to do some digging.
In short, it still is a struggle with visualgdb. I followed your last recipy, but with no success.
My opinion is that above solutions may all be a workaround, but it should work out of the box. But from who can I expect some? Sysprogs tells it is the lowlevel openocd, but st will say it is working with openocd (st fork) inside our IDE.
Both are right, but where lies the solution?

BR Martin

 

 

[mcipjvw]

Hi,

Experiment of copying the TestIDE.cfg file to the VisualGDB environment showed that cfg files are not exchangeble.
See error:

target/stm32l0x.cfg:53: Error: Command: STM32L071KZTx.dap Exists in procedure ‘script’
at file “embedded:startup.tcl”, line 28
at file “target/stm32l0x.cfg”, line 53

Ok… Exchanging binaries or cfg files gives some more insight on the underlying problem perhaps, but it is not working.
I got stuck…

I hope that you have some options left. Switching to the STM32CubeIDE is not actually an option…..

BR Martin

 

 

 

 

[mcipjvw]

Hi,

A little bit further! I first copied the openocd binaries from the STM32CubeIDE to the visualgdb location. Just an error on the “–set “CHIPNAME $$SYS:MCU_ID$$Xx”” command: “unknown option — set”.
By removing this option parameter, the adapter is successfully detected. However, with warnings -> DEPRECATED! use ‘read_memory’ not ‘mem2array’. Further, erasing/programming is failing. I think due to the configured and reappearing ‘– set’ parameter. Can’t figure out where it comes from.

I will try to use the TestIDE.cfg file now.

BR Martin

[mcipjvw]

Hi,

Good suggestion. I installed the STM32CubeIDE and programming worked using the stlink-v3pwr adapter.
So, stlink drivers and OpenOCD using the ST fork seem fine. Programming with VisualGDB though still not, despite the selection of the ST fork cfg.
Looking at the arguments, some differences can be remarked.

CubeIDE:

openocd.exe “-f” “TestIDE.cfg” “-s” “C:/Users/xxxxx/STM32CubeIDE/workspace_1.12.1/TestIDE” “-s” “C:/ST/STM32CubeIDE_1.12.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.0.600.202303311036/resources/openocd/st_scripts” “-s” “C:/ST/STM32CubeIDE_1.12.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mpu.debug.openocd_2.0.500.202301161420/resources/openocd/st_scripts” “-c” “gdb_report_data_abort enable” “-c” “gdb_port 3333” “-c” “tcl_port 6666” “-c” “telnet_port 4444”

VisualGDB:

-f interface/stlink-dap.cfg –set “CHIPNAME $$SYS:MCU_ID$$Xx” -f target/stm32l0x.cfg -c init -c “reset init”

Some configuration needs to be done I suppose 😉

Thanks for the quick response. Looking forward for your ideas.

Martin

 

• This reply was modified 11 months, 3 weeks ago by mcipjvw.

[mcipjvw]

Hi, seems that I have a similar problem. Now with the new stlink-v3pwr adapter. Latest version of visualgdb (VisualGDB-5.6r9) did not solve the problem. Manual adding the VID/PID to the edp.xml and QuickSetup files gives the ST-link v3 adapter in the list but gives an error “stlink_usb.c:3431 stlink_usb_usb_open(): read version failed”. The stlink seems correctly installed as “stlink-bridge” and “stlink debug” devices.

Any idea? I am looking forward!

Martin

 

• This reply was modified 11 months, 3 weeks ago by mcipjvw.
• This reply was modified 11 months, 3 weeks ago by mcipjvw.

[mcipjvw]

Hi,

Thanks for your reply. I just played with the adapter speed. Setting to 1200 kHz did the job for now. Remarkable that programming with the stm32cube programmer does not give any problem.

Martin

 

[mcipjvw]

Hi,

I’ve a simular problem here with my stm32l071, see the log below. A wiring problem seems not to be the issue here,  the “STM32CubeProgrammer” does the programming well.

Tried two boards….

Any news around this topic? Did you solve the problem?

Thnx

Martin

Open On-Chip Debugger 0.10.0 (2017-06-09) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport “hla_swd”. To override use ‘transport select <transport>’.
adapter speed: 240 kHz
adapter_nsrst_delay: 250
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
Info : clock speed 240 kHz
Info : STLINK v2 JTAG v31 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.184252
Info : stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x0800b324 msp: 0x20005000
STM32L0: Enabling HSI16
adapter speed: 1800 kHz
VisualGDB_OpenOCD_Ready
Info : accepting ‘gdb’ connection on tcp/64516
Info : Device: STM32L0xx (Cat.5)
Info : STM32L flash has dual banks. Bank (0) size is 96kb, base address is 0x8000000
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x0800b324 msp: 0x20005000
STM32L0: Enabling HSI16
adapter speed: 1800 kHz
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x0800b324 msp: 0x20005000
STM32L0: Enabling HSI16
adapter speed: 1800 kHz
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000000e msp: 0x20005000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000000e msp: 0x20005000
Error: jtag status contains invalid mode value – communication failure
Info : Previous state query failed, trying to reconnect
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x20000006 msp: 0x20005000
Error: error writing to flash at address 0x08000000 at offset 0x00000000
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1389). Workaround: increase “set remotetimeout” in GDB
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x0800b324 msp: 0x20005000

• This reply was modified 5 years, 1 month ago by mcipjvw.

[Author]

Posts