07:20 <Heisey> PaulFertser, thanks for the reply:

07:20 <Heisey> This is the OpenOCD output: https://pastebin.com/gsHpi2ir

07:20 <Heisey> This is the GDB output: https://pastebin.com/xDRgBeHu

07:20 <Heisey> I am not sure if CLion allows typing GDB commands interactively, but I'll find out

07:47 <PaulFertser> Heisey: hey

07:49 <PaulFertser> Heisey: is there a list of OpenOCD and/or GDB commands it runs?

07:50 <PaulFertser> Heisey: are are you able to run same OpenOCD binary with same config manually and try to run it with -c "init; halt; verify_image /path/to/your/elf" ?

07:50 <Heisey> I'll try it

07:56 <PaulFertser> Heisey: also, it looks like CLion uses "program" procedure to flash it on startup but it doesn't include "verify" optional argument, why?

07:57 <PaulFertser> Heisey: does "flash size = 1536 KiB" match your MCU features?

07:57 <PaulFertser> "xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc" with flashed image looks like the flash is empty, that is strange.

07:59 <Heisey> it's not programming the flash, that much I do know because I can open the flash from other tools (such as the ST programmer)

07:59 <Heisey> "flash size = 1536 KiB" does seem to match the MCU

08:00 <Heisey> when I connect to the MCU from the ST Utility I can see th flash size and its contents

08:00 <PaulFertser> Heisey: ok, are you using an elf file to flash? Can you run openocd -f /your/board.cfg -c "program /path/to/your/elf verify exit"?

08:00 <Heisey> yes

08:00 <PaulFertser> Please do and show :)

08:01 <Heisey> https://pastebin.com/YcDqHRYW

08:02 <Heisey> oh sorry

08:03 <Heisey> that was the last thing you said, let me run the other thing

08:04 <Heisey> https://pastebin.com/xsUwmGkb - here, it seems to be able to program and verify

08:04 <PaulFertser> Heisey: interesting, that verify image worked properly and values are expected, so it was flashed with this image before.

08:04 <Heisey> what I'll try now is erase the flash with the other tools and do that again

08:04 <PaulFertser> xPSR: 0x21000000 pc: 0x0800186a msp: 0x2004ff74 <-- see it's right address of reset vector and stack pointer somewhere at the end of RAM

08:05 <PaulFertser> Heisey: you can erase with OpenOCD too.

08:05 <PaulFertser> Heisey: -c "init; flash erase_sector 0 0 last; shutdown"

08:07 <Heisey> yeah okay, so it does seem to be able to erase and program

08:07 <PaulFertser> Heisey: so let's check the commands that CLion gives it.

08:08 <Heisey> I wonder if I need some hackery to do that

08:08 <PaulFertser> Heisey: unlikely, it should be in some config

08:10 <Heisey> where should I look in your opinion? I could also talk to the JetBrains people to ask them

08:11 <PaulFertser> Heisey: btw, https://resources.jetbrains.com/help/img/idea/2023.3/cl_embed_openocdconfig.png shows "reset init" selected, but reset init is only appropriate before flashing, and after flashing it should do "reset halt" to have a fully clean state. "reset init" is a special thing to prepare for maximum speed reliable flashing and shouldn't be used prior to debug.

08:11 <PaulFertser> Heisey: yes, worth discussing that with them, as that's a commercial product and you should have support. I suggest you mention the "reset init" thing too.

08:12 <PaulFertser> The question is how exactly they implemented download there and why it's not verifying.

08:13 <Heisey> yeah I changed it to reset halt via the UI

08:13 <Heisey> let me show you

08:13 <PaulFertser> Heisey: btw, not sure if you're familiar with a concept of hack space, so just mentioning in case you're not: there's a place TAMI it Tel Aviv where you can often meet nice people and use some nice tools for your hobby projects.

08:14 <Heisey> https://pasteboard.co/6rbI4zK2YmMX.png

08:14 <Heisey> nice, pretty cool

08:15 <Heisey> I haven't used IRC for programming stuff in over a decade... this is bringing me back :)

08:15 <Heisey> using pastebin, image pasting and all that

08:17 <PaulFertser> Heisey: usually there's a way to specify some init commands for GDB. So you can have CLion just start OpenOCD without flashing, and to the list of GDB commands add "load" (it flashes current elf to target) and "compare-sections".

08:17 <Heisey> I can also try a plugin that supports OpenOCD instead of using their built-in support

08:17 <PaulFertser> There must be some way in CLion to configure that, probably just not in GUI.

08:20 <PaulFertser> The plugin has source available https://github.com/elmot/clion-embedded-arm

08:21 <Heisey> it looks pretty old... I am guessing they took this plugin and made it a part of the IDE since then?

08:24 <Heisey> they're calling their plugin "Embedded Development Support" now

08:24 <PaulFertser> Yes they did

08:24 <PaulFertser> Probably didn't change the flashing part though.

08:25 <PaulFertser> Heisey: I see it generates an additional UPLOAD target in the CMake file.

08:25 <PaulFertser> Heisey: so you should be able to just manually edit CMakeLists instead

08:28 <PaulFertser> (instead of using that GUI dialogue)

08:28 <PaulFertser> We really need to get in contact with JetBrains to explain them the deal about this "reset init" thing.

08:28 <PaulFertser> It's breaking assumptions.

08:29 <PaulFertser> And that "program" should better receive "verify" optional argument there.

08:30 <Heisey> yeah I'll try to talk to them... they actually have a Discord server for stuff, but it's probably better to open a ticket on their site

08:31 <Heisey> trying to do stuff directly from OpenOCD should have been my first goto... I banged the head against the wall for hours yesterday :)

08:33 <PaulFertser> Heisey: you disappeared suddenly after asking though

08:34 <PaulFertser> Try to see if editing CMakeLists in your project allows you to add verify there.

08:37 <PaulFertser> And in general, it shouldn't be using "program" or reset or anything like that manually. It has "monitor" commands which means it's all going through GDB already. And gdb has native "load" command which properly flashes the target if the elf maps to flash and uploads to RAM if it maps elsewhere. No need to reset, no need to specify anything, just simple "load".

08:37 <Heisey> oh you think they're doing that? having GDB do all these bits?

08:39 <Heisey> I had this IRC session open at the work computer and left

08:40 <Heisey> I'd suggest to also have a Discord server, but I know that people are allergic to the idea :)

08:41 <PaulFertser> D is actively abuses free software developers, it's an anti-user service.

08:41 <PaulFertser> Yes, I see "monitor" commands in their template.

08:41 <PaulFertser> That's a way to send to OpenOCD directly via GDB. But GDB knows how to flash with any GDB server, it's just "load".

08:42 <Heisey> so it's possible that it's their bundled GDB that's causing issues?

08:45 <PaulFertser> Heisey: unlikely. I'm yet to understand what's actually happening without seeing the commands it runs.

08:46 <PaulFertser> Heisey: but if editing our project file CMakeLists.txt manually works then we can do it.

08:46 <PaulFertser> You can add "monitor log_level 2" before the flashing command and we'll see much more.

08:47 <Haohmaru> how about.. replace openocd with a proxy script that relays the commands but also prints them somewhere

08:47 <Heisey> I don't see any mention of OpenOCD or GDB commands in the CMakeLists file

08:48 <Heisey> well I don't need to use a script for seeing the interaction between the processes... I could use something like Process Monitor

08:48 <Haohmaru> well, i'm no h4x0r, that's as much as i could think of

08:51 <Heisey> not technically hacking :)

08:54 <PaulFertser> Heisey: hm, can you try to grep through whole project directory for "UPLOAD" ?

08:54 <PaulFertser> Eh, probably it's not in cmake file after all and just hardcoded in plugin source :/

08:56 <PaulFertser> Yes, sorry, I see it now.

08:56 <PaulFertser> Well, this plugin isn't that great apparently.

08:56 <PaulFertser> You can just run OpenOCD manually and have CLion configured as with any other GDB server for remote debugging.

08:56 <PaulFertser> There you surely can add custom GDB commands.

08:58 <Heisey> the plugin worked though and is easy to set up and replicate, which is the frustrating part... but if I understand you correctly, you're suggesting to run OpenOCD & GDB directly (presumably from CLion) and then attach to it as a GDB target?

08:59 <PaulFertser> I suggest to run OpenOCD manually in another terminal and ask CLion to run GDB for you.

09:00 <PaulFertser> And just specify "extended-remote :3333" for the GDB target.

09:00 <PaulFertser> The plugin needs some fixes but it's hard to tell what exactly is wrong with it because it's so inflexible and doesn't allow to raise debugging level or some such.

11:26 <Heisey> PaulFertser, okay so I managed to get it to work by using the ST Link's GDB server (effectively what the ST Cube IDE is using) and figuring out what the ST IDE tells GDB to do and applying it from CLion

11:27 <PaulFertser> Heisey: but not OpenOCD proper?

11:27 <Heisey> set *(int *)0xE000EDFC=*(int *)0xE000EDFC|0x7F0

11:27 <Heisey> I am still not sure what this does

11:27 <Heisey> not yet

11:27 <PaulFertser> This thing is some tricky thing for RAM boot, shouldn't be relevant.

11:28 <PaulFertser> Probably no, I need to check.

11:28 <Heisey> it used to have a "monitor reset" command in CLion by default

11:28 <Heisey> let me try getting rid of that set

11:30 <Heisey> I think the monitor reset is what messed things up

11:31 <PaulFertser> Yes, that's some internal register for proper debug, OpenOCD sets it automatically when appropriate.

11:31 <Heisey> so it's resetting that ruins it for me

11:31 <PaulFertser> "monitor reset" is "reset run" so it lets the target run the flashed code. Unlikely you want to have it in debug session, you want "monitor reset halt".

11:31 <Heisey> ah

11:32 <Heisey> yeah because the flashed code isn't going to the program, but to some bootloader

11:32 <Heisey> and if the bootloader is not present then it doesn't do anything

11:33 <Heisey> damn did I speak to the ether?

11:33 <Heisey> [2:31:34 PM] <PaulFertser> "monitor reset" is "reset run" so it lets the target run the flashed code. Unlikely you want to have it in debug session, you want "monitor reset halt".

11:33 <Heisey> [2:31:52 PM] <Heisey> ah

11:34 <Heisey> [2:32:14 PM] <Heisey> yeah because the flashed code isn't going to the program, but to some bootloader

11:34 <Heisey> [2:32:26 PM] <Heisey> and if the bootloader is not present then it doesn't do anything

11:35 <PaulFertser> Heisey: no it was all here

11:36 <Heisey> I'll take a break from this because I actually have to get some work done

11:36 <PaulFertser> Heisey: bootloader where, in ROM?

11:36 <Heisey> no, it's in the flash also

11:36 <PaulFertser> ROM bootloader is always there.

11:36 <PaulFertser> Oh you have bootloader in flash!

11:36 <PaulFertser> And your elf has no bootloader, right?

11:36 <PaulFertser> And probably CLion invocation erases the bootloader somehow?

11:36 <PaulFertser> That would kinda explain the behaviour.

11:37 <Heisey> no the CLion invocation shouldn't erase the bootloader, but even if it did it shouldn't be a problem as long as I'm not using the device in production

11:38 <Heisey> but it doesn't start the program for some odd reason

11:39 <Heisey> either way it works with CLion + the ST gdbserver for now, but it's frustrating that I can't get it to work with OpenOCD yet

11:39 <Heisey> I'll research this when I have more time... I really have to improve my knowledge on debuggers somehow

11:40 <Heisey> maybe I can convince JetBrains to put their Embedded Support Plugin on an open repository so I can maybe play around with it myself

11:40 <Heisey> what was that group in Tel-Aviv you mentioned earlier? I am curious

11:48 <PaulFertser> Heisey: https://telavivmakers.org/welcome

11:49 <PaulFertser> Facilities: https://telavivmakers.org/tamiwiki/space

11:53 <Heisey> cool cool

11:53 <Heisey> thanks a lot for all the help

11:53 <Heisey> I'll look into getting JetBrains to fix those OpenOCD issues

11:54 <PaulFertser> Heisey: feel free to ping me when you get more info. It's really hard to tell without seeing what's going on. Probably later when you have more time you can use ProcessMonitor to capture full invocation command line and reproduce it without clion.