kopia lustrzana https://github.com/stlink-org/stlink
![]() |
||
---|---|---|
build | ||
example | ||
src | ||
AUTHORS | ||
LICENSE | ||
README |
README
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'.