STM32L053 Discovery & openOCD

[hammerfet]

Hello,

I’m having a bit of a nightmare trying to set up a project for STM32L0 devices using openOCD with an ST-Link debugger.

I’m trying to use the 0.8.0-r6 openOCD release that is listed within the “install debugger packages” window. With automatic settings I’ve been getting device ID errors. Using the manual options for openOCD I tried having a play around with the tcl scripts to see if I could fix it.

I went into the “stm32lx_stlink.cfg” file that is automatically selected by default. In there I changed the “CPUTAPID” value to 0x0bc11477. This was the device ID that the output console say it had detected.

After this openOCD was able to get a little further. Now I get a GDB error:

Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v17 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.892453
Info : stm32lx.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : accepting 'gdb' connection from 3333
Error: attempted 'gdb' connection rejected

So various other things I’ve tried include using the newer openOCD source files but that was getting messy, I’ve tried both STlink-v2 and v2.1. I don’t think theres a problem with these as I’m able to manually upload .bin files to my devices using the STlink utility.

I’ve tried multiple boards, one custom board as well as an STM32L053 discovery board. I’ve also tried using the texane ST-link debug package but that’s not working.

I suspect it’s a problem with GDB now, I have a setting wrong somewhere for the debugger? Am I correct in thinking that the STM32L0 series only supports SWD? This is my stm32lx_stlink.cfg file:

if { [info exists CHIPNAME] == 0 } {
   set CHIPNAME stm32lx
}

if { [info exists CPUTAPID] == 0 } {
   set CPUTAPID 0x0bc11477
}

if { [info exists WORKAREASIZE] == 0 } {
   set WORKAREASIZE 0x2800
}

source [find target/stm32_stlink.cfg]

# Flash base address is known by driver. Flash size will be probed.
#
# Please note that the larger stm32lx targets (256Kb and 384Kb) uses dual
# bank flash. For such targets use target/stm32lx_dual_bank.cfg.
#
# Some samples of ST's stm32lx chips are known to have incorrect flash size
# values programmed in their FLASH_SIZE register. The driver will warn
# for strange values. It is possible to override the flash size probe by
# defining the correct size here. Notice though that it is the size of
# the flash bank
#
# flash bank stm32lx <base> <size> 0 0 <target#> <variant>
set _FLASHNAME $_CHIPNAME.flash
#flash bank $_FLASHNAME stm32lx 0 0 0 0 $_TARGETNAME
flash bank $_FLASHNAME stm32lx 0x08000000 0 0 0 $_TARGETNAME

proc stm32l_enable_HSI {} {
 # Enable HSI as clock source
 echo "STM32L: Enabling HSI"

 # Set HSION in RCC_CR
 mww 0x40023800 0x00000101

 # Set HSI as SYSCLK
 mww 0x40023808 0x00000001
}

$_TARGETNAME configure -event reset-init {
 stm32l_enable_HSI
}

$_TARGETNAME configure -event reset-start {
 adapter_khz 300
}

 

• This topic was modified 8 years, 11 months ago by hammerfet.
• This topic was modified 8 years, 11 months ago by hammerfet.

[hammerfet]

I’ve just been looking in the edb.xml file and found this:

<string>target remote :3333</string>

Previously I’ve driven GDB from the command line using st-util.exe and arm-none-eabi-gdb.exe like this:

st-util.exe

arm-none-eabi-gdb output\output.elf -ex target extended-remote localhost:4242

Is it possible that the default port and host address is wrong?

• This reply was modified 8 years, 11 months ago by hammerfet.

[bitbybit]

I was on the same journey as you with STM32L0, OpenOCD & ST-Link v2.1.
I could flash the chip using STLink but not get a debug session.

The solution for me was to get a Segger J-Link Debug Probe and everything works smoothly with VisualGDB debugging through SWD now.

 

[sd_tom]

I am also having problems with STM32F103 and openOCD..  It either is complaining about timeouts or fails to write in certain circumstances..  think it has to do with offsetting from base address to not erase a bootloader i have at the base of flash.

However, the Texane ST-Link works ok.. so I may just use that;  is there any drawback to using the Texane plugin vs openocd?

Still evaluating visualGDB overall as a product.   Since the eval code from ST came with a CoIDE (also gnu compiler) i’ve had a lot of compare/contrasting going on.   CoIDE seems the more polished product vs visualgdb (just looking at the comments in their files (a lot more helpful) vs equivalent sections in the visualGDB generated files for one).   Still find it tempting due to visualstudio vs eclipse but it’s not making the decision easy.

[support]

Hi,

We will add an OpenOCD 0.9.0 package as a part of the upcoming VisualGDB 5.0 release. It should improve the integration with the new ST devices. The main issue of the Texane tool is that sometimes it leaves the ST-Link in an invalid state and does not start another session unless you unplug and replug it. OpenOCD does not have this problem.

Could you provide some examples of things poorly documented in VisualGDB project samples so that we could improve that?

[sd_tom]

sure let me dig it up.. i noticed it when i went “standalone” because I needed to change the linker script to offset my application.. so was doing some diffing with CoIDE’s equivalent BSP files (startup_,system_, etc) but I will try to find an explicit example. That reminds me (sorry to totally thread derail); the provided linker script from visualgdb said it was autogenerated from some linker script tool on sysprogs.com but the URL was broken.

Re 0.9.0 – I was able to replace the openocd.exe and the entire scripts folder in my visualgdb area and was able to switch easily to test if it made things better.

• This reply was modified 8 years, 10 months ago by sd_tom.

[Author]

Posts