kopia lustrzana https://github.com/stlink-org/stlink
96 wiersze
3.1 KiB
Plaintext
96 wiersze
3.1 KiB
Plaintext
HOWTO
|
|
=====
|
|
|
|
First, you have to know there are several boards supported by the software.
|
|
Those boards use a chip to translate from USB to JTAG commands. The chip is
|
|
called stlink and there are 2 versions:
|
|
. STLINKv1, present on STM32VL discovery kits,
|
|
. STLINKv2, present on STM32L discovery and later kits.
|
|
|
|
2 different transport layers are used:
|
|
. STLINKv1 uses SCSI passthru commands over USB,
|
|
. STLINKv2 uses raw USB commands.
|
|
|
|
It means that if you are using a STM32VL board, you have to install and load
|
|
SCSI related software. First, load the sg kernel module:
|
|
# modprobe sg
|
|
|
|
Then, you need to install the package libsgutils2-dev. On Ubuntu:
|
|
# sudo apt-get install libsgutils2-dev
|
|
|
|
LIBUSB is required for both cases.
|
|
|
|
To run the gdb server, do (you do not need sudo if you have set up
|
|
permissions correctly):
|
|
$ make -C build && sudo ./build/st-util [/dev/sgX]
|
|
|
|
Currently, the GDB server listening port is hardcoded to 4242:
|
|
|
|
Then, in gdb:
|
|
(gdb) target remote :4242
|
|
|
|
Have fun!
|
|
|
|
Resetting the chip from GDB
|
|
===========================
|
|
|
|
You may reset the chip using GDB if you want. You'll need to use `target
|
|
extended-remote' command like in this session:
|
|
(gdb) target extended-remote localhost:4242
|
|
Remote debugging using localhost:4242
|
|
0x080007a8 in _startup ()
|
|
(gdb) kill
|
|
Kill the program being debugged? (y or n) y
|
|
(gdb) run
|
|
Starting program: /home/whitequark/ST/apps/bally/firmware.elf
|
|
|
|
Remember that you can shorten the commands. `tar ext :4242' is good enough
|
|
for GDB.
|
|
|
|
Setting up udev rules
|
|
=====================
|
|
|
|
For convenience, you may install udev rules file, 10-stlink.rules, located
|
|
in the root of repository. You will need to copy it to /etc/udev/rules.d,
|
|
and then either reboot or execute
|
|
$ udevadm control --reload-rules
|
|
|
|
Udev will now create a /dev/stlink file, which will point at appropriate
|
|
/dev/sgX device. Good to not accidentally start debugging your flash drive.
|
|
|
|
Running programs from SRAM
|
|
==========================
|
|
|
|
You can run your firmware directly from SRAM if you want to. Just link
|
|
it at 0x20000000 and do
|
|
(gdb) load firmware.elf
|
|
|
|
It will be loaded, and pc will be adjusted to point to start of the
|
|
code, if it is linked correctly (i.e. ELF has correct entry point).
|
|
|
|
Writing to flash
|
|
================
|
|
|
|
The GDB stub ships with a correct memory map, including the flash area.
|
|
If you would link your executable to 0x08000000 and then do
|
|
(gdb) load firmware.elf
|
|
then it would be written to the memory.
|
|
|
|
FAQ
|
|
===
|
|
|
|
Q: My breakpoints do not work at all or only work once.
|
|
|
|
A: Optimizations can cause severe instruction reordering. For example,
|
|
if you are doing something like `REG = 0x100;' in a loop, the code may
|
|
be split into two parts: loading 0x100 into some intermediate register
|
|
and moving that value to REG. When you set up a breakpoint, GDB will
|
|
hook to the first instruction, which may be called only once if there are
|
|
enough unused registers. In my experience, -O3 causes that frequently.
|
|
|
|
Q: At some point I use GDB command `next', and it hangs.
|
|
|
|
A: Sometimes when you will try to use GDB `next' command to skip a loop,
|
|
it will use a rather inefficient single-stepping way of doing that.
|
|
Set up a breakpoint manually in that case and do `continue'.
|