Update README.

[fw/stlink] / README

diff --git a/README b/README
index 986169702cf2d84a3de349ba4a547958092e9d3f..c94177bac1714011fc1926386e9254c94260c4fb 100644 (file)
--- a/README
+++ b/README
@@ -1,5 +1,47 @@
-cd build
-make
+HOWTO
+=====
 
-edit Makefile
-make run
+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 1234 /dev/sg1
+
+Then, in gdb:
+(gdb) target remote :1234
+
+Have fun!
+
+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'.