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.
This branch should work for F1 and F4 devices. It has currently been tested
with F1 value line, (a VL discovery board) programmed via gdb via both an
stlinkv1 and an stlinkv2.
F4 has _not_ yet been tested on this branch
Conflicts:
.gitignore
doc/tutorial/tutorial.pdf
example/blink/main.c
gdbserver/Makefile
gdbserver/gdb-server.c
src/stlink-common.c
src/stlink-common.h
src/stlink-usb.c
All the device params like flash size and page size should all be in the core open routines, not
_only_ in the gdbserver. (This should stop it from ending up duplicated in the core, and get rid of
some of the hacks that were turning up. All of this is chip specific!)
In the future, we might actually want device names back again, if you have multiple stlink's
connected. But that would be a new device name, not scanning for /dev/sgX looking for scsi
devices.
Supports setting the gdb listen port
Supports setting which version of stlink to use
Supports setting the device to use (in case autoprobing doesn't work)
Conflicts:
build/Makefile
gdbserver/gdb-server.c
This merges in the bulk of bravikov's work on the command line and automatic sensible defaults for
the gdb server
Modified by karlp to merge the two 0x416 devices
Modified to add F1 to the F1 devices and sort by device id
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
As noted, the usb transfer only has a 1 byte length, but it also has a different mode
to enter.
Tidied up and removed more duplicate and hard coded code, tried to add some notes on
where the magic came from.
No idea where the chip ids came from, I can't find them in the datasheets anywhere.
Move towards a standard libstlink, with backends for libusb (stm32l discovery) and scsi
passthrough (stm32vl discovery) and a common front end.
Verified that stm32l branch works much the same, but more to go for stm32vl.
Michael Pratt