STLink connection to ST32L433

TomV 2018-03-22 05:30:53 UTC #1

I'm trying to get openocd to talk to the STM32 uC through an STLink v2 dongle.

I can make it work with one of those $2.50 STM32F103C8T6 development boards, so the dongle is fine, but when I use the STM32 on the BlackIce board, I get this:

ubuntu@ubuntu-xenial:~$ sudo /usr/local/bin/openocd -f stlink.cfg
Open On-Chip Debugger 0.10.0
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>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 500 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : clock speed 480 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.234369
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'

The stlink.cfg file is the one found in ./firmware/Src:

source [find interface/stlink-v2.cfg]
source [find target/stm32l4x.cfg]
gdb_memory_map enable

I've connect the GND, SWCLK, and SWDIO wires between the STLink dongle and the board. I've also tried connecting the RST pin of the dongle to the RESET_ pin of the board, but that didn't have any effect.

The presence of the stlink.cfg file in the firmware repo makes me think that somebody was able to get this going.

Any suggestions?

Tom

TomV 2018-03-23 06:42:14 UTC #2

I suspect that the issue is due to signal quality.

While I haven't managed to get the STLink dongle to work (yet), I now have something much better.

See my project log here:

One day, I'll write that up in manual form for the wiki.

Tom

lawrie 2018-03-23 08:56:19 UTC #3

I seem to have an ST Link and a blue pill from experiments I did with an STM32 a year or two ago:

So I will attempt to repeat what you have done with BlackMagic Probe.

Then I want to get GDB and OpenOCD working from a Raspberry Pi over the RPi header.

TomV 2018-03-23 14:34:47 UTC #4

You’re probably looking at something like this:

That should work if you modify the pin assignments.

Tom

TomV 2018-03-24 06:34:36 UTC #5

I can now successfully blink the DBG1 LED, controlled by the STM32, using libopencm3.

As always, it took a lot more trial and error than expected, and I even had to use the STLink dongle instead of the Black Magic Probe!

Details are here: https://hackaday.io/project/92800/log/127820-debugging-my-first-stm32-program-on-the-blackice-ii-board

Speaking of the STLink dongle: I got that one to work by also adding one extra GND wire between the dongle and the BlackIce-II board. The strange thing is that I originally only used the GND pin which sits right between the SWCLK and SWDIO pins of the RPi connector (pin 9). You'd think that this would give the best results... But it only starts working when I also wire up pin 25.

Tom

TomV 2018-03-24 20:20:13 UTC #6

And here's the recipe to run programs from RAM instead of ROM:

Change the linker script such that the code points to RAM instead of ROM (0x20000000 instead of 0x08000000) and compile.

Start openocd

sudo openocd -f /usr/local/share/openocd/scripts/interface/stlink.cfg -f /usr/local/share/openocd/scripts/target/stm32l4x.cfg

Start gdb:

arm-none-eabi-gdb -ex "target remote localhost:3333" cdcamc.elf

You should seem something like this:

Reading symbols from cdcacm.elf...done.
Remote debugging using localhost:3333
0x08000232 in ?? ()

Note that the STM32 was still running something in the 0x0800000 address range.

Load the binary into memory:

load

You will get this:

(gdb) load
Loading section .text, size 0x4f4 lma 0x20000000
Start address 0x2000045c, load size 1268
Transfer rate: 9 KB/sec, 1268 bytes/write.

Set a breakpoint:

(gdb) br main
Breakpoint 1 at 0x20000188: file cdcacm.c, line 298.

Execute your code:

c

(gdb) c
Continuing.

Breakpoint 1, main () at cdcacm.c:298
298	{
(gdb) c
Continuing.

Yes. It's as simple as that: instead of "run", you need to use "continue", and it will do exactly what you need: execute your program in RAM.

It's interesting that openocd doesn't even allow the 'run' command, so I was forced to use continue. Not so for the Black Magic Probe, which supports both. I'm sure that by using 'continue' on the Black Magic, I'll be able to run from RAM instead of ROM just the same.

Tom