cp- has quit [Quit: Disappeared in a puff of smoke]
cp- has joined #openocd
dreamcat4 has quit [Quit: Connection closed for inactivity]
Guest92 has quit [Quit: Client closed]
olerem has quit [Ping timeout: 240 seconds]
shoragan has quit [Ping timeout: 260 seconds]
shoragan has joined #openocd
olerem has joined #openocd
tsal has quit [Ping timeout: 260 seconds]
tsal has joined #openocd
Hawk777 has joined #openocd
c4017 has joined #openocd
<c4017>
First time trying openocd with an stlink, I get "Error: 18 71 hla_interface.c:264 hl_interface_handle_layout_command(): No adapter layout 'stlink' found" when running with "-d3 -f interface/stlink.cfg -f target/stm32f4x.cfg -c "init; reset init""
<c4017>
I built with --enable-stlink, is anything else needed?
<PaulFertser>
c4017: hi
<PaulFertser>
c4017: probably you're running not the binary you built?
<c4017>
PaulFertser, I verified it's the correct binary. Actually I first tried it with another binary that was built without '--enable-stlink' and got a different error "Error: 16 79 adapter.c:135 handle_adapter_driver_command(): The specified debug interface was not found (hla)"
<PaulFertser>
c4017: another guess then: you're running a binary with configs from another OpenOCD version.
<c4017>
oh I think I figured it out...
<c4017>
I had '--disable-stlink' later in the command line haha
<c4017>
yup, working now
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
nerozero has joined #openocd
<PaulFertser>
c4017: cool :) should have been reflected in configure summary at the end.
<c4017>
yup that's how I eventually found it
Xogium has quit [Quit: Leaving.]
Xogium has joined #openocd
Hawk777 has quit [Quit: Leaving.]
Haohmaru has joined #openocd
Bertl_zZ is now known as Bertl_oO
In0perable has quit [Quit: All your buffer are belong to us!]
<josuah>
hello! any news about the RP2040? As popular as it looks, their $1 133MHz MCU is still having a separate fork, with not much thing that moves on their side
<Haohmaru>
why aren't there nice SWD debuggers tho
<Haohmaru>
nice and cheap
<Haohmaru>
or at least nice
<karlp>
there are?
<Haohmaru>
not many
<bencoh>
olimex/jlink are pretty nice in my opinion
<karlp>
multi drop litereally didn't exist for years, and wsa worked around in single drop swd for many many multi core targets.
<Haohmaru>
i meant DAPlink based
<bencoh>
oh
<Haohmaru>
or SWDAP
<Haohmaru>
you know, the CMSIS thing
<karlp>
I'm not sure what the question is here?
<Haohmaru>
none, ignore me
Haohmaru has quit []
<josuah>
karlp: thank you! I understand this all so very better now!
nerozero has quit [Ping timeout: 260 seconds]
Steffann has joined #openocd
Steffanx has quit [Ping timeout: 256 seconds]
Steffann is now known as Steffanx
<karlp>
hope I got it all right then ;)
<josuah>
the SWD doc and RP2040-datasheet.pdf seems to confirm
<josuah>
karlp: or maybe not!
<karlp>
oh, those bits were right, the claims on fw updates may or not be required for multi drop swd on most common dongles is perhaps a bit fluffier
<josuah>
answer from he who made pico-debug (running an SWD debugger on one core for debugging the other):
<josuah>
> NO. This is not the case. CMSIS-DAP is a USB protocol to connect PC software running ARM debug software to an ARM debug unit on an ARM MCU. You are mistakenly interpreting descriptions about SWD as somehow being a description of CMSIS-DAP.
<josuah>
> RaspberryPi chose to create their own proprietary protocol that is layered on top a USB virtual serial UART port and uses that UART protocol to conduct SWD transfers. They did this instead of adopting an open standard like CMSIS-DAPv2.
<karlp>
that's different though,
<karlp>
and where's that from anyway?
<karlp>
because it was literally raspberrypi.org people who contributed the multi drop swd code to openocd, before they could even say what the target was...
<karlp>
anyway, openocd.zylin.com/6075 is merged too,
<karlp>
I'm not sure what else you would need from rpi fork now.
<josuah>
pico-debug is not picoprobe I think
<josuah>
that was from openocd.zylin.com/6075 's author
<josuah>
or let me check...
<karlp>
kilograham?
<karlp>
or majbthrd?
<josuah>
majbthrd
<karlp>
ok, so then, if I can read between the lines, kilograham was paid by arm to add multi drop swd support to openocd, _prior_ to the rp2040 being announced, but as soon as it came out, we knew what it had been for.
<karlp>
in the meantime, rpi people went, "fuck it, this is taking to long, we're going to do something else in the meantime"
<josuah>
oh my!
<karlp>
and /me shrugs
<josuah>
that is very valuable for me to understand
<karlp>
just fucking avoid this proprietary garbage fire.
<karlp>
I was not aware they had actually gone with something "not arm standrd multi drop swd"
<karlp>
because, see aforementioned trashfire comment.
<karlp>
much better to deal with riscv "totally not proprietary" trash fires instead ;)
<karlp>
I may still be misinterpretting, and I was _not_ involved in tracking these chagnes,
<karlp>
though I don't have lot of sympahty for majbthrd feeling like "all this work" to "actualyl follow style, and not leak memory"....
<josuah>
ooh, "SWD v2" in the datasheet, not "DAP v2"
<karlp>
it wouldn'tsurprise me if yould actualyl use both?
<karlp>
also, the fact they haven't even changed the readme indicates they still believe in the lie they're telling themself that this is "just a short lived fork, we'll get it upstream, hoenst"
<karlp>
but now it's like they found some community people to maintain the fork....
<josuah>
I felt there was something odd with that fork
<josuah>
but I was not expecting peeking at so much of this story
<karlp>
well, you bought into the rpi world :)
<josuah>
reinventing the next-gen wheel in an incompatible way?
HelloShitty has quit [Ping timeout: 256 seconds]
<karlp>
look at it another way, what mad eyou pick rp2040 for your project? :)
<karlp>
eh, don't mind me being grumpy
<karlp>
one of the targets i'm playing with has a _binary only_ openocd fork :|
<karlp>
at least you get source :)
<josuah>
karlp: I do NOT feel you too grumpy! Enjoying getting a bit more grasp of the situation
<josuah>
I first picked RP2040 out of a compromise: very cheap for their power, making it useable for a lot of various tools
<karlp>
how do you decide the "power" metric?
<josuah>
I looked at what was offered on other MCUs for the same price
<josuah>
I thought I misread somewhere: completely out of the range of what one can find for that price
<josuah>
but still not extreme face to ESP32
<josuah>
borderline unfair: price or good engineering can make a product sell well
<josuah>
but it looked over-engineered: a lot of boiler plate code required for just blinking a led
HelloShitty has joined #openocd
<josuah>
after figuring out how the RESETS.RESET regsiter worked, I finally could give-up the SDK and figure out it was not as bad as I thought
<josuah>
and then the PIO units made me want to try doing something, like a LIN master for instance
<josuah>
not picking RP2040 for a particular project, looking at what to explore next... Open to suggestions :)
zjason` has joined #openocd
zjason has quit [Read error: Connection reset by peer]
<josuah>
"price or good engineering can make a product sell well" and I feared that the RP2040 would flood the market due to its price, regardless of the eventual bad design choices, which I had not enough knowledge to evaluate
<josuah>
> _binary only_ openocd fork
<josuah>
is that not forbidden by GPLv2?
emeb has quit [Quit: Leaving.]
toobah has joined #openocd
<toobah>
yo if anyone is around im in a real bind
<toobah>
about a FreeBSD build of the raspberry pi port of openocd
toobah has quit [Client Quit]
toobah has joined #openocd
toobah has quit [Client Quit]
toobah has joined #openocd
toobah has quit [Client Quit]
toobah has joined #openocd
toobah has quit [Ping timeout: 256 seconds]
toobah has joined #openocd
toobah has quit [Quit: Ping timeout (120 seconds)]
<josuah>
raspberry pi fork doing wonders again
<josuah>
I'll wait he's back
<josuah>
or maybe building the original openocd package for a raspberry pi target