HOWTO: Hardware debugging STM32F030 and STM32F103 with ST-LINK V2 on FreeBSD. - Page 1
Forum section: electronics / general

author: rhodges
author_rank: Frequent Contributor
timestamp: June 16, 2020, 05:40:47 pm
content: This is somewhat specific to FreeBSD, but I some will find it interesting. The process should be similar for Linux users.My goal is to do programming and hardware debugging for the STM32F030 and STM32F103. I will be using the cheap ($3) ST-LINK V2 USB adapters. I will be using the STM32F demo boards I got on ebay.Steps:1. Get permission to the USB device(s) using devfs and a new group.2. Install the ARM cross-compiler.3. Install OpenOCD for programming and access to gdb.4. Create new OpenOCD target for the "fake" STM32F103 chips.5. Create gdb init files for STM32F030 and STM32F1036. Connect to device with OpenOCD.7. Run arm-gdb, program a device, and step through it.There are a lot of lines here, so I will break this down into multiple postings.

author: rhodges
author_rank: Frequent Contributor
timestamp: June 16, 2020, 05:41:47 pm
content: The first step is to get FreeBSD to give me permission to access the ST-LINK USB device. Since I am not sharing my computer, I will simply give myself access to all of the USB devices. I will create a group called "usb_rw" and make "devfs" give r/w permissions to that group.Add to /etc/rc.conf:devfs_system_ruleset="localrules"Add to /etc/devfs.rules[localrules=9]add path 'usb/*' mode 0660 group usb_rwCreate group "usb_rw" and add myself to that group:pw groupadd usb_rwpw groupmod usb_rw -M rh (that's me)I am not familiar with devfs, so I just restarted the computer.Now when I look at /dev/usb, I see this:crw-rw---- 1 root usb_rw 0x31 Mar 30 13:02 0.1.0crw-rw---- 1 root usb_rw 0x57 Mar 30 13:02 0.1.1crw-rw---- 1 root usb_rw 0x33 Mar 30 13:02 1.1.0crw-rw---- 1 root usb_rw 0x55 Mar 30 13:02 1.1.1...NOTE: If you plan to use SIGROK/Pulseview, you will want to do this.

author: rhodges
author_rank: Frequent Contributor
timestamp: June 16, 2020, 05:43:17 pm
content: STEP #2: Install the ARM cross-compiler.pkg install gcc-arm-embeddedAdd the ARM tools to your path:/usr/local/gcc-arm-embedded/bin/STEP #3: Install OpenOCD for programming and access to gdb.pkg install openocdSTEP #4: Create new OpenOCD target for the "fake" STM32F103 chips.cd /usr/local/share/openocd/scripts/target/cp stm32f1x.cfg stm32fake103.cfgvi stm32fake103.cfg(change 0x1ba01477 to 0x2ba01477)

author: rhodges
author_rank: Frequent Contributor
timestamp: June 16, 2020, 05:43:55 pm
content: STEP #5: Create gdb init files for STM32F030 and STM32F103.Let's say your paths to your STM32F030 and STM32F103 are:/usr/home/{you}/stm32f030/usr/home/{you}/stm32f103Create a gdb init file /usr/home/{you}/.gdbinit with:add-auto-load-safe-path /usr/home/{you}/stm32f030/.gdbinitadd-auto-load-safe-path /usr/home/{you}/stm32f103/.gdbinitIn your STM32F030 directory, create .gdbinit with:target remote localhost:3333monitor reset haltset remote hardware-breakpoint-limit 4set remote hardware-watchpoint-limit 2In your STM32F103 directory, create .gdbinit with:target remote localhost:3333monitor reset haltset remote hardware-breakpoint-limit 6set remote hardware-watchpoint-limit 4For a different chip, OpenOCD will tell you how many breakpoints andwatchpoints your chip has.

author: rhodges
author_rank: Frequent Contributor
timestamp: June 16, 2020, 05:46:11 pm
content: STEP #6 Connect to device with OpenOCD.Open a separate terminal window to run openocd. Here I am starting openocd for the STM32F030:openocd -f interface/stlink-v2.cfg -f target/stm32f0x.cfgOpen On-Chip Debugger 0.10.0Licensed under GNU GPL v2For bug reports, readhttp://openocd.org/doc/doxygen/bugs.htmlInfo : 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/SWDadapter speed: 1000 kHzadapter_nsrst_delay: 100none separateInfo : Unable to match requested speed 1000 kHz, using 950 kHzInfo : Unable to match requested speed 1000 kHz, using 950 kHzInfo : clock speed 950 kHzInfo : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748Info : using stlink api v2Info : Target voltage: 3.244269Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints

author: rhodges
author_rank: Frequent Contributor
timestamp: June 16, 2020, 05:47:50 pm
content: STEP #7: Run arm-gdb, program a device, and step through it.arm-none-eabi-gdb test_binhex.elf[lots of gdb messages trimmed](gdb) loadLoading section .isr_vector, size 0xc0 lma 0x8000000Loading section .text, size 0xa24 lma 0x80000c0Loading section .rodata, size 0x154 lma 0x8000ae4Loading section .ARM, size 0x8 lma 0x8000c38Loading section .init_array, size 0x4 lma 0x8000c40Loading section .fini_array, size 0x4 lma 0x8000c44Loading section .data, size 0x68 lma 0x8000c48Start address 0x80009f4, load size 3248Transfer rate: 3 KB/sec, 464 bytes/write.(gdb) b mainBreakpoint 1 at 0x8000186: file test_binhex.c, line 45.(gdb) cContinuing.Note: automatically using hardware breakpoints for read-only addressesBreakpoint1, main () at test_binhex.c:4545 board_init();(gdb) l40 int main(void){41 char display;42 int i, i2, i3, errs;43 char data;4445 board_init();4647 local_setup();48 clock_init(clock_ms, clock_10);49 uart_init(UART1, BAUD_115200);(gdb) n47 local_setup();(gdb) n48 clock_init(clock_ms, clock_10);(gdb)We are now debugging with the $3 ST-LINK device

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 18, 2020, 11:47:30 pm
content: I did not read all your posts here, but want to add 2 small things.Back when I used STM32 I very much liked the STM32 primer from pandafruits. (I got as far as a working GDB command line).Some of the "Blue Pill" boards from china have incompatible chips and apparently debugging does not work for those.