Allow custom TCL port for `-p ocd` about humility HOT 5 OPEN

We'd certainly look at something that would allow for port customization. I would also caution that I'm not sure how much we're going to want to use OpenOCD/GDB long term. We've been much more focused on probe.rs (https://probe.rs/) or something just using SWD support. This is also still very much an area under development and seeing new approaches that create a better debugging experience is always appreciated.

from humility.

https://github.com/probe-rs/vscode I'd be interested if this looks like it would fit your needs

from humility.

Yup, heard of it! Excited to hear that it's gaining momentum too. I had checked it out a year or so ago and it showed pretty great promise, but at the time I didn't have a clear reason to jump ship from my hodgepodge of OpenOCD/GDB/various VSCode extensions. That said, I did end up using it through the Humility usb ProbeCore pathway to mess around with the hiffy commands, since it doesn't appear the OpenOCD or GDB cores support write_8.

The one thing I'm not terribly familiar with is if it supports multiple simultaneous connections like OpenOCD does, or requires exclusive access to the USB device. My particular use case was being able to set breakpoints in the various tasks within VSCode, allowing me to halt the core + interrupts and inspect local/global variables in the debugger, then connect Humility via TCL to dump core, probe ring buffers, check stack headroom, look at registers etc; things that the native debug interface doesn't support.

I suppose a pipe dream would be to proxy the debugger directly through Hubris, removing the dual connection requirement entirely while still allowing Hubris's debug functions in parallel. Of course I realize this is completely unrealistic in even the moderate-term 😅 ; only bringing it up since the debug experience is still under discussion.

I'll give the probe-rs VSCode extension a shot and report back whether I can get it to play nice with Hubris's connection.

from humility.

Somewhat tangentially related: I know Oxide is in full sprint mode with the imminent product ship date, but are you considering accepting PRs to Hubris and/or Humility now or in the future? I'd be happy to upstream features like this if so (along with a tiny PR to add support for the STM32H7(2|3)* series chips in stm32_chipname)

Happy for PRs! PRs for Humility are especially welcome because they (generally) need less scrutiny. Hubris can be a little more complicated because there is work that folks may wish to do that effectively increase our engineering burden (e.g., support for a new board or chipset). In terms of this specific issue: would happily take a PR to specify the port for the OpenOCD target. As @labbott mentions, it's not necessarily where we want to be in the indefinite future, but specifying the port is entirely reasonable.

from humility.

Sounds good! I'll see what I can do about a quick PR to add the port as a parameter.

On the probe-rs side of things, I seem to have run into a dead end. While I did get the VSCode extension working with probe-rs, unfortunately Hubris' build pipeline doesn't end up copying the section headers from the source ELF task files when assembling the combined.srec, only the relevant PT_LOAD progream headers sections. Based on Cliff's talk I suspect this may be by design...? Hubris gets around this in OpenOCD by writing the script.gdb file that includes the various add-symbol-file to the un-stripped task ELFs (additionally fixing the paths using set substitute-path). AFAICT at the moment probe-rs doesn't support external symbols, and thus can't set breakpoints or unwind the stack when debugging. Please do let me know if that's the case and I've just missed a flag or three in probe-rs-debugger! :)

Overall not a problem; OpenOCD does work for my setup and I can get a Hubris image up and running on my STM32H723.

from humility.