SIGINT causes st-util to immediately exit, without closing the open
stlink. This leaves devices (at least the F4 Discovery) in a state
where they are unable to reset. st-util could still connect and control
them, but a power cycle was required before they could reset on their
own.
A signal handler is added for SIGINT, which performs cleanup and closing
of the open stlink device, allowing it to function normally on
disconnect.
When started with -m, or connected with 'target extended-remote', the
GDB server will not terminate upon disconnection from GDB, instead it
will begin listening for conenctions again.
Starting with extended-remote also has the advantage of allowing 'run'
to be used to reset the target and begin again. Unfortunately, 'start'
is not working properly, as it does not send a reset packet (R), so it
complains when it tries to access memory before it is connected to the
target.
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.
Michael Pratt