kopia lustrzana https://github.com/stlink-org/stlink
General Project Update
- Minor documentation fixes - HOWTO and FAQ --> tutorial.mdpull/885/head
nightwalker-87
rodzic
f1acc8b34a
commit
c8a2f133f0
|
|
@ -39,9 +39,9 @@ Updates and fixes:
|
|||
* Added howto for sending NRST signal through GDB ([#774](https://github.com/texane/stlink/pull/774), [#776](https://github.com/texane/stlink/pull/776), [#779](https://github.com/texane/stlink/pull/779))
|
||||
* Fixed package name "devscripts" in doc/compiling.md ([#775](https://github.com/texane/stlink/pull/775))
|
||||
* Fixed few potential memory/resource leaks ([#803](https://github.com/texane/stlink/pull/803))
|
||||
* Updated Linux source repositories in README.md: Debian and Ubuntu ([#821](https://github.com/texane/stlink/pull/821), [#835](https://github.com/texane/stlink/pull/835), [#859](https://github.com/texane/stlink/pull/859))
|
||||
* Do not issue JTAG reset on stlink-v1 ([#828](https://github.com/texane/stlink/pull/828))
|
||||
* Fixed flash size of STM32 Discovery vl ([#829](https://github.com/texane/stlink/pull/829))
|
||||
* Updated Linux source repositories in README.md: Debian and Ubuntu ([#821](https://github.com/texane/stlink/pull/821), [#835](https://github.com/texane/stlink/pull/835), [#859](https://github.com/texane/stlink/pull/859))
|
||||
* Updated documentation on software structure ([#851](https://github.com/texane/stlink/pull/851))
|
||||
|
||||
General project updates:
|
||||
|
|
|
|||
123
README.md
123
README.md
|
|
@ -142,126 +142,3 @@ openocd: "\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x31"
|
|||
Try to remove the write protection (probably only possible with ST Link Utility from ST itself).
|
||||
|
||||
Issue related to this bug: [#545](https://github.com/texane/stlink/issues/545)
|
||||
|
||||
|
||||
# HOWTO
|
||||
## Using the gdb server
|
||||
|
||||
To run the gdb server:
|
||||
|
||||
```
|
||||
$ make && [sudo] ./st-util
|
||||
|
||||
There are a few options:
|
||||
|
||||
./st-util - usage:
|
||||
|
||||
-h, --help Print this help
|
||||
-vXX, --verbose=XX Specify a specific verbosity level (0..99)
|
||||
-v, --verbose Specify generally verbose logging
|
||||
-s X, --stlink_version=X
|
||||
Choose what version of stlink to use, (defaults to 2)
|
||||
-1, --stlinkv1 Force stlink version 1
|
||||
-p 4242, --listen_port=1234
|
||||
Set the gdb server listen port. (default port: 4242)
|
||||
-m, --multi
|
||||
Set gdb server to extended mode.
|
||||
st-util will continue listening for connections after disconnect.
|
||||
-n, --no-reset
|
||||
Do not reset board on connection.
|
||||
```
|
||||
|
||||
The STLINKv2 device to use can be specified in the environment
|
||||
variable `STLINK_DEVICE` in the format `<USB_BUS>:<USB_ADDR>`.
|
||||
|
||||
Then, in your project directory, someting like this...
|
||||
(remember, you need to run an _ARM_ gdb, not an x86 gdb)
|
||||
|
||||
```
|
||||
$ arm-none-eabi-gdb fancyblink.elf
|
||||
...
|
||||
(gdb) tar extended-remote :4242
|
||||
...
|
||||
(gdb) load
|
||||
Loading section .text, size 0x458 lma 0x8000000
|
||||
Loading section .data, size 0x8 lma 0x8000458
|
||||
Start address 0x80001c1, load size 1120
|
||||
Transfer rate: 1 KB/sec, 560 bytes/write.
|
||||
(gdb)
|
||||
...
|
||||
(gdb) continue
|
||||
```
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
If you need to send a hard reset signal through `NRST` pin, you can use the following command:
|
||||
|
||||
```
|
||||
(gdb) monitor jtag_reset
|
||||
```
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
|
||||
## Writing Option Bytes
|
||||
|
||||
Example to read and write option bytes (currently writing only supported for STM32G0 and STM32L0)
|
||||
```
|
||||
./st-flash --debug --reset --format binary --flash=128k read option_bytes_dump.bin 0x1FFF7800 4
|
||||
./st-flash --debug --reset --format binary --flash=128k write option_bytes_dump.bin 0x1FFF7800
|
||||
```
|
||||
|
||||
|
||||
## 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`.
|
||||
|
||||
Q: Load command does not work in GDB.
|
||||
|
||||
A: Some people report XML/EXPAT is not enabled by default when compiling GDB. Memory map parsing thus fail. Use --enable-expat.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Release
|
||||
=======
|
||||
|
||||
This document describes the steps takes for developers to create a release
|
||||
This document describes the steps it takes for developers to create a release
|
||||
|
||||
1. Update `.version` with semantic version: `x.x.x`
|
||||
2. Update `README.md` with semantic version `x.x.x` in commits badge
|
||||
|
|
|
|||
138
doc/tutorial.md
138
doc/tutorial.md
|
|
@ -37,7 +37,7 @@ Before continuing, the following dependencies must be met:
|
|||
|
||||
Also make sure `gtk+` version 3.0 is installed. (`sudo apt-get install gtk+-3.0` or similiar)
|
||||
|
||||
STLINK should run on any system meeting the above constraints.
|
||||
STLINK should run on any system meeting the above constraints.
|
||||
|
||||
The STLINK software source code is retrieved using:
|
||||
|
||||
|
|
@ -62,7 +62,6 @@ It includes:
|
|||
|
||||
Using the GDB server
|
||||
====================
|
||||
|
||||
|
||||
This assumes you have got the libopencm3 project downloaded in `ocm3`.
|
||||
The libopencm3 project has some good, reliable examples for each of the
|
||||
|
|
@ -85,11 +84,11 @@ the discovery kit you are using, you must run one of the 2 commands:
|
|||
$> ./st-util --stlinkv1
|
||||
|
||||
# STM32L or STM32F4 discovery kit (onboard ST-link/V2)
|
||||
$> ./st-util
|
||||
$> ./st-util
|
||||
|
||||
# Full help for other options (listen port, version)
|
||||
$> ./st-util --help
|
||||
```
|
||||
```
|
||||
|
||||
Then, GDB can be used to interact with the kit:
|
||||
|
||||
|
|
@ -113,7 +112,7 @@ command line, now we can simply “load” the target:
|
|||
|
||||
```
|
||||
(gdb) load
|
||||
```
|
||||
```
|
||||
|
||||
st-util will load all sections into their appropriate addresses, and
|
||||
“correctly” set the PC register. So, to run your freshly loaded program,
|
||||
|
|
@ -127,6 +126,7 @@ Your program should now be running, and, if you used one of the blinking
|
|||
examples from libopencm3, the LEDs on the board should be blinking for
|
||||
you.
|
||||
|
||||
|
||||
Building and flashing a program
|
||||
===============================
|
||||
|
||||
|
|
@ -154,7 +154,7 @@ It is also possible to write a hexfile which is more convinient:
|
|||
$> ./st-flash --format ihex write myapp.hex
|
||||
```
|
||||
|
||||
####
|
||||
####
|
||||
|
||||
Of course, you can use this instead of the gdb server, if you prefer.
|
||||
Just remember to use the “.bin” image, rather than the .elf file.
|
||||
|
|
@ -167,6 +167,132 @@ $> [sudo] ./st-flash write fancy_blink.bin 0x08000000
|
|||
|
||||
Upon reset, the board LEDs should be blinking.
|
||||
|
||||
|
||||
HOWTO
|
||||
=====
|
||||
## Using the gdb server
|
||||
|
||||
To run the gdb server:
|
||||
|
||||
```
|
||||
$ make && [sudo] ./st-util
|
||||
|
||||
There are a few options:
|
||||
|
||||
./st-util - usage:
|
||||
|
||||
-h, --help Print this help
|
||||
-vXX, --verbose=XX Specify a specific verbosity level (0..99)
|
||||
-v, --verbose Specify generally verbose logging
|
||||
-s X, --stlink_version=X
|
||||
Choose what version of stlink to use, (defaults to 2)
|
||||
-1, --stlinkv1 Force stlink version 1
|
||||
-p 4242, --listen_port=1234
|
||||
Set the gdb server listen port. (default port: 4242)
|
||||
-m, --multi
|
||||
Set gdb server to extended mode.
|
||||
st-util will continue listening for connections after disconnect.
|
||||
-n, --no-reset
|
||||
Do not reset board on connection.
|
||||
```
|
||||
|
||||
The STLINKv2 device to use can be specified in the environment
|
||||
variable `STLINK_DEVICE` in the format `<USB_BUS>:<USB_ADDR>`.
|
||||
|
||||
Then, in your project directory, someting like this...
|
||||
(remember, you need to run an _ARM_ gdb, not an x86 gdb)
|
||||
|
||||
```
|
||||
$ arm-none-eabi-gdb fancyblink.elf
|
||||
...
|
||||
(gdb) tar extended-remote :4242
|
||||
...
|
||||
(gdb) load
|
||||
Loading section .text, size 0x458 lma 0x8000000
|
||||
Loading section .data, size 0x8 lma 0x8000458
|
||||
Start address 0x80001c1, load size 1120
|
||||
Transfer rate: 1 KB/sec, 560 bytes/write.
|
||||
(gdb)
|
||||
...
|
||||
(gdb) continue
|
||||
```
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
If you need to send a hard reset signal through `NRST` pin, you can use the following command:
|
||||
|
||||
```
|
||||
(gdb) monitor jtag_reset
|
||||
```
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
|
||||
## Writing Option Bytes
|
||||
|
||||
Example to read and write option bytes (currently writing only supported for STM32G0 and STM32L0)
|
||||
```
|
||||
./st-flash --debug --reset --format binary --flash=128k read option_bytes_dump.bin 0x1FFF7800 4
|
||||
./st-flash --debug --reset --format binary --flash=128k write option_bytes_dump.bin 0x1FFF7800
|
||||
```
|
||||
|
||||
|
||||
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`.
|
||||
|
||||
Q: Load command does not work in GDB.
|
||||
|
||||
A: Some people report XML/EXPAT is not enabled by default when compiling GDB. Memory map parsing thus fail. Use --enable-expat.
|
||||
|
||||
|
||||
Notes
|
||||
=====
|
||||
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue