Support was tested by attaching USB cable to USB ST-LINK USB port, starting
./st-util
Which resulted in proper device recognition:
2012-11-03T23:11:25 INFO src/stlink-common.c: Device connected is: F3 device, id 0x10016422
2012-11-03T23:11:25 INFO src/stlink-common.c: SRAM size: 0xa000 bytes (40 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes
Chip ID is 00000422, Core ID is 2ba01477.
Then from GDB, after "target remove localhost:4242", I tested reads:
x/w 0x20000000
And writes:
set {int}0x20000000 1
And ELF loading:
(gdb) load main
Loading section .text, size 0x10 lma 0x20000000
Start address 0x20000000, load size 16
Transfer rate: 410 bytes/sec, 16 bytes/write.
And verified dissasembly (in my case--with Thumb mode) with objdump -d <elf>
output:
(gdb) set arm force-mode thumb
(gdb) x/7i 0x20000000
=> 0x20000000: push {r7}
0x20000002: sub sp, #12
0x20000004: add r7, sp, #0
0x20000006: ldr r3, [r7, #4]
0x20000008: add.w r3, r3, #1
0x2000000c: str r3, [r7, #4]
0x2000000e: b.n 0x20000006
The extra registers added in my previous commit can now be modified from
within GDB. Since the ST-LINK does not support accessing these
registers, a workaround was used from reading an writing to them.
That is, the Debug Core Register Selector Register (DCRSR) can be written
with the register requested, and it will be read/written to/from the
Debug Core Register Data Register (DCRDR). The standard ST-LINK memory
access functions are used to make these accesses.
A target descriptor XML file is sent to GDB from the server, which tells
GDB which registers exist on the target.
This is only supported for the STM32F4, and has only been tested on the
STM32F4DISCOVERY. I tested st-util on an STM32L-DISCOVERY and my
changes did not seem to interfere with its operation.
Since the ST-LINK does not seem to support reading these registers, I
have implemented functions that will manually request these registers
and add them to the reg struct.
As of now, these functions are just backend and are not integrated into
anything, however I have verified that they work with the STM32F407
DISCOVERY board.
They should be in a standalone repository, that can focus on clean,
easy to follow, well documented, well tested examples.
If you just want some example binaries that you can use to test your
installation is working, the libopencm3 project has various blink
projects for all the STM32 Discovery boards.
Dave Murphy