06:52 <borneoa___> PaulFertser: what Hawaka said about two GDB connections is that some IDE use a second GDB as a trick to resolve the symbols of the variables and display the values while the first GDB keeps the target running. We have a flag max-gdb-connections or similar to allow it's, with default to 1. It's a potential issue if the second GDB try to operate on the target, but it's up to the IDE to guarantee it doesn't happen

08:18 <PaulFertser> borneoa___: I see. Hawaka didn't mention using any tricks like that, it requires something like $TARGETNAME configure -gdb-max-connections 2 so not default and should be mentioned in the report.

21:17 <Hawaka_> Hello, while doing more testing and preparing the log files, I noticed that I was actually wrong yesterday. The live expression does not work with the st-link and the openOCD extension. It only works with a "STM32 application" debug configuration. Therefore I believe my problem is STM32cubeIDE, and not openOCD. Regarding the 2 gdb connection, I think this is how the live expression is

21:17 <Hawaka_> implemented on ST IDE (-gdb-max-connections is set to 2 when creating the target).

21:26 <PaulFertser> Hawaka_: hi

21:28 <PaulFertser> Anyway, st-link or cmsis-dap shoudn't matter at all when you use OpenOCD with that target.

21:36 <Hawaka_> In STM32cubeIDE, you have to create a "debug configuration", which is sort of a setup for debugging, where you chose most of the debug setup (like what kind of probe, location of elf file, flash program or only attach, ...). They are regroup by "type", like pyocd, openocd and stm32 application.

21:39 <Hawaka_> Anyway as I don’t think the live expression gonna work with my probe, I’m gonna try other IDE. Probably VSCode and cortex debug. Shame because I think that the debugging experience in st IDE is very good. Any comment on a good IDE / debugger?

21:54 <PaulFertser> vscode + cortex debug should be good

21:54 <PaulFertser> ST even managed to screw up downloading of their IDE components, guess they do not really want people use it.

22:07 <Hawaka_> If you use their debugger and the toolchain as they intend you to, it’s pretty good once setup. Otherwise yeah not so good

22:07 <PaulFertser> Hawaka_: nope, not really.

22:07 <PaulFertser> Hawaka_: it requires Internet access and ST account to install.

22:07 <PaulFertser> Now imagine you want it on an air-gapped machine.

22:08 <PaulFertser> Or just having temporary difficulties exactly at the moment you need it.

22:09 <PaulFertser> There's a long thread about it on their forums where people clearly explain how it harms big time with ST just playing dumb in response.

22:09 <PaulFertser> I was quite disappointed to read it.

22:19 <Hawaka_> I understand your point, personnally the debugging experience is more important for me, as I am lucky enough not to have comply with such constrains. But yeah for sure it’s not perfect.

22:23 <PaulFertser> I'm used to debug in plain GDB. As a bonus I can do it over ssh comfortably, so the board can be on the other side of the globe.

22:26 <PaulFertser> BTW, did you know ST crippled their st-link v3 on purpose, so unlike v2 it can not be used with non-ST targets at all?

22:30 <Hawaka_> I did not know it. That really a corporate greed move... I usually use the manufacturer probe to avoid headache. The one good thing about ST is that their probe are cheap. The blackhawk TI probes are like 300USD and break easily

22:34 <PaulFertser> Luckily many TI targets are supported by OpenOCD so you can use any probe.

23:35 <Jon39> anyone using the adafruit ft232h breakout bored ... having all kinds of trouble with it detecting my connected target ... and if not many people are here ... anyone know how active the channel is?