HOWTO
=====

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.

Caveats
=======

GDB sends requests for a multi-sectioned ELF files (most ones;
having both .text and .rodata is enough) in a quite strange way which
absolutely does not conform to flash page boundaries. Which is even more
weird when you think about FlashErase requests which it sends correctly.
And I couldn't think of a way which will resolve this correctly now.

Hardware breakpoints are not supported yet. You can still run your code from
RAM, and then GDB will insert `bkpt' opcodes automagically.

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'.