<sevan>
PaulFertser: no, but I did try on modern macOS (intel) & Ubuntu 23.10 amd64
<PaulFertser>
sevan: let's try to solve it, what's the current state?
<sevan>
PaulFertser: the st-link v1 device didn't work on modern macOS as you described (I'm not disabling SIP & loading an unsigned kext).
<sevan>
PaulFertser: on Ubuntu, openocd could do the right & I could interact with the st-link v1 device via telnet.
<PaulFertser>
sevan: (I thought it's kinda odd you still have stm32vldiscovery board as that was the first ever stm32 board I had; but then I realised it's not suprising for someone running PowerPC Mac; why old OS X though and not GNU/Linux?)
<sevan>
PaulFertser: <3
<PaulFertser>
sevan: ok, so v1 problem is clear, you need to somehow convince OS X to let the device go, probably by unloading usb mass storage kext altogether.
<sevan>
PaulFertser: agreed
<PaulFertser>
But v2 should work, let's see what about it.
<sevan>
PaulFertser: I want to work on but have to head out shortly. I can drop by later this evening.
<PaulFertser>
sevan: sure
<PaulFertser>
sevan: init mode failed really means some miswiring though
<PaulFertser>
GND or Vcc not connected probably. Or SWCLK mixed with SWDIO. Or you're attaching to wrong lines or probably if you're trying same vl board it means you didn't disconnect jumpers that go to stlinkv1 that's on board etc.
<sevan>
PaulFertser: the v2 devices I have are the st-link v2 clone adapters, they are unlocked & I've flashed them with the stock firmware using the official st-link utility
<PaulFertser>
sevan: yes, that should be good
<PaulFertser>
Do you have an oscilloscope or logic analyser? Just to exclude the possibility the labels on those clone adapters are wrong and the SWD lines are miswired somehow.
<PaulFertser>
sevan: doesn't matter in this case. Something's wrong with the wiring. Or probably the target isn't powered?
<PaulFertser>
sevan: or probably the target is in sleep mode or has SWD disabled?
<PaulFertser>
(to exclude the last two ideas pull target's reset line low while trying to start OpenOCD)
<sevan>
LED on the adapter is on
<sevan>
when you say it isn't powered? it's in the usb slot (there are no buttons on the device)
<sevan>
how can I check if SWD is disabled?
<PaulFertser>
sevan: what is your target device atm? How is it connected to power?
<PaulFertser>
sevan: to check if SWD is disabled pull target's reset low and re-run OpenOCD and see if it changed.
<sevan>
that's what I'm saying, I don't have anything attached to the SWD OUT pins on the adapter
<PaulFertser>
sevan: what do you expect then? Without target you can't debug a target :)
<sevan>
:D
<sevan>
so I can't interact with the device itself, it's simply a means to connect to another device which I would like to debug?
<PaulFertser>
sevan: stlink is a debug adapter, yes, it's used to debug other targets.
<sevan>
I will disable the st-link v1 interface on the stm32-discovery & try connecting that up (I did try it earlier this morning but still failed)
<PaulFertser>
sevan: remove both jumpers yes and connect stlink to target stm32f100, that should work.
<sevan>
ack
<sevan>
I skipped on the VDD pin & just powered the stm32f100 via USB as I read something scary about the clone adapters supplying power. That should still be ok, right?
<PaulFertser>
sevan: yes, should be ok
<PaulFertser>
sevan: never connect a clone adapter to a non-3.3 V target though
<sevan>
ah, noted. So the 5V pins are a lie?
<PaulFertser>
No, they are directly connected to USB Vcc so you can use them to power the target if it has a 3.3 V LDO or something
<sevan>
permacomputing, you can fish out these things out of the dump because they're out of fashion & the ancient OS has full support for the hardware
<sevan>
PaulFertser: it's all wrong, I had to butcher it
<sevan>
PaulFertser: just that I have to go back and fix it correctly.
<sevan>
PaulFertser: that line specially 0b01 fails because it is not treated as hex
<sevan>
so GCC complains about b01
<PaulFertser>
sevan: I'm asking about software, not hardware
<sevan>
If I prefix it with 0x, GCC complains that there are more issues
<sevan>
PaulFertser: are you referring to OS X?
<PaulFertser>
Yes
<sevan>
supports the hardware well, and there's a whole bunch of professional creative software for it.
<sevan>
saying that, I hear good things about Linux on macpc since IBMs work for power applied to some of these systems, e.g virtualisation. I tried other "not linux" open source operating systems on them & the focus there is more on the operating systems support for the target than actually being able to use the machine for making music, editing, ...
<PaulFertser>
I see makes sense indee.
<sevan>
Regarding openocd, I had to disable armv8 support because there are many cases with hex numbers being referenced without a prefix so I ripped it out just to plough on.
<sevan>
As is documented in src/helper/options.c, realpath is expected to be POSIX 2008 implementation I'll break that out for Darwin so that on older system it does the right thing.
<sevan>
The MIN macro conflicts with something in the system's header files regarding networking :)
<sevan>
And lastly, linker is too on this system to recognise -rpath. :)
<sevan>
I think the issues in armv8 support, src/flash/nor/xcf.c, realpath would be worth fixing and upstreaming since there's broader impact.
<PaulFertser>
We do not really target retro computers normally
<sevan>
ack
<PaulFertser>
If it's something simple and doesn't increase maintenance why not. But when it gets more involved, probably not worth it given already rather limited time the maintainers have.
<PaulFertser>
And I personally do not review patches for few years already as I'm not using OpenOCD anymore with the new job.
<sevan>
got it :)
<sevan>
btw, now that I actually have something connected up correctly, st-info reports a bit more detail https://paste.debian.net/1305575/ (I trimmed the serial)
<sevan>
src/flash/nor/xcf.c:133:46: error: invalid suffix "b01" on integer constant
<sevan>
src/flash/nor/xcf.c:134:46: error: invalid suffix "b01" on integer constant
<sevan>
src/flash/nor/xcf.c:531:10: error: invalid suffix "b1111" on integer constant
<sevan>
hmm, prefixing those with 0x satisfied GCC
<sevan>
two "minus ones" on the review. wrong solution :)
MGF_Fabio has joined #openocd
<PaulFertser>
sevan: I thought you're joking and not actually submitting that for review
<PaulFertser>
I have to note this joke is kinda silly
<PaulFertser>
It was catchy enough to make "avrdude" author reply!