09:33 <embcla> hello everyone, hopefully this is the right place to ask. have got a local configuration that's able to manage (flash, reset, unlock) an STM32G0. I run it like "openocd -f unlock.cfg". Now how do I get it to to the same stuff remotely via gdb/vscode?

11:31 <karlp> _one_ method, is to make your script in your unlock a function instead,

11:31 <karlp> so you would have to use -f hoho.cfg -c "myfunction" at the command line,

11:32 <karlp> but then you could use "monitor myfunction"

11:32 <karlp> alternatively, you can make a gdb function def that just calls the monitor commands to execute each line of your script one by one.

11:33 <karlp> you _generally_ don't want to do things like flashing and reseting behind gdb's back, it can get confused about expected state

12:19 <embcla> thanks karlp, is the netiquette to write single lines? I don't remember IRC rules anymore, such a long time

12:19 <embcla> until recently I was using STMCubeProgrammer, STLink and ST IDE.

12:19 <embcla> Then I needed to move from my laptopt to the tools I have in the office and those run on arm, and the ST tools don't, so I can't use ST own tools.

12:20 <embcla> That's where openocd comes into the picture, and so I started hunting and found different scripts that I stitched together

12:20 <embcla> and that's where I am now: I can do the basics by directly calling openocd, and now I want to debug and step through code

12:20 <embcla> if my approach is not compatible with gdb, then how do I go at making it compatible?

12:21 <embcla> keep in mind I also have an architecture issue: my laptop runs amd64, the intermediate machine that's connected to the DUT is armv7, the target is cortex m0

12:22 <embcla> so on armv7 I have the cortex configuration and run openocd with an open socket for gdb to connect to

12:23 <embcla> then from my machine on amd64, I run vscode with cortex-debug, and connect to the remote session

12:23 <embcla> and that's where I'm having a ton of issues, cause gdb is not fully synchronized with all the things I need to do to the target, and I don't know how to sync it

12:40 <embcla> example: to start debugging, I need to unlock first, then flash, the image is a binary not an executable, so I need to say the offset. my scripts do these, but how should I do this within gdb and why?

13:27 <PaulFertser> embcla: I think with "monitor" command you can just "source /path/to/your/script"

13:27 <PaulFertser> embcla: basically if you run -f unlock.cfg then you should be able to "monitor source unlock.cfg"

13:28 <PaulFertser> embcla: but why do you need anything special at all? You can run any OpenOCD command with "mon <openocd tcl code>"

13:38 <karlp> oh yeah, source exists :)

13:38 <karlp> why doyou need to unlock first? if you're doing development, can you just leave it unlocked?

13:38 <PaulFertser> Good question :)

13:38 <karlp> anwway, otherwise, just use "load" in gdb, it will do reflash for you nicely, and keep things in sync

13:39 <PaulFertser> Yeah

13:39 <karlp> just "load; run" ad nauseum, it will pick up changed .elf files and reflash for you

13:39 <PaulFertser> load in GDB works for ELF files, and you do not need any manual offset specifications.

14:58 <embcla> well it's a prod firmware, so it has all sorts of normal company security measures. disabling all is not easy, because until now it was not worth the hassle of making arrangements to do so

14:58 <embcla> so what I need to flash is a bin that goes through a process where its stripped and then its own crc is appended to it, so no elf format

14:59 <embcla> and the software locks itself up during boot, which I can't easily disable, so I need to unlock before flashing

15:00 <embcla> so on vscode side I have everything (both the elf and the bin), but on target side I need the bin and I need to unlock

15:01 <embcla> and what's the best way of doing all of this with gdb and openocd in between is where I'm stuck

17:16 <PaulFertser> embcla: it's not normal to prevent end-user from reading out firmware...