jfsimon has quit [Remote host closed the connection]
jfsimon has joined #openocd
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #openocd
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #openocd
jfsimon has quit [Max SendQ exceeded]
jfsimon has joined #openocd
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #openocd
ALTracer has joined #openocd
nerozero has joined #openocd
snaz has joined #openocd
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #openocd
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #openocd
zjason` is now known as zjason
ALTracer has quit [Quit: Quit]
diddly has quit [Quit: leaving]
Haohmaru has joined #openocd
diddly has joined #openocd
Hawk777 has quit [Quit: Leaving.]
Xogium has quit [Remote host closed the connection]
Xogium has joined #openocd
<mawk>
but that's only for the raspberrypi 5 PaulFertser
<mawk>
at least in the develop branch of openocd
<mawk>
can I just port it to a rpi4 >?
Xogium has quit [Remote host closed the connection]
Xogium has joined #openocd
lh has quit [Remote host closed the connection]
geep has quit [Remote host closed the connection]
bryanb has quit [Remote host closed the connection]
<Haohmaru>
crapberry pie is the new hammer that shall be used to hit every problem like it's a nail
key2 has joined #openocd
defiant has joined #openocd
<PaulFertser>
mawk: libgpiod (current Linux interface) is as generic as sysfsgpiod (deprecated interface)
<PaulFertser>
mawk: and it's certainly upstream, available for Linux everywhere.
<PaulFertser>
It's not going to be much faster than sysfsgpio of course but at least it should be safe to use multiple instances concurrently.
<mawk>
so I can reuse the raspberrypi5.cfg file and it should work
<mawk>
if I remove the weird PCI stuff first
<mawk>
because there's no interface configuration file that's for libgpiod alone it seems
<mawk>
Haohmaru: it's better than buying 6 stlinks
<mawk>
I want one pi to program as many devices as possible
<mawk>
everytime someone pushed his code
<Haohmaru>
are you programming the same .elf or something?
<mawk>
and if I can fit more devices on it I can have a longer queue for the gitlab runner
<mawk>
yeah
<mawk>
the latest one that got built in gitlab
<mawk>
it's a regular gitlab runner
<Haohmaru>
maybe it's time to make a Parallel SWD programmer? ;P~
<mawk>
well that's what I'm trying to do
<mawk>
currently it's a serial parallel SWD programmer
<mawk>
but it's not really a problem the programming is so fast
<mawk>
I can live with waiting for the programming to finish
<Haohmaru>
nah, you're just (ab)using a SBC ;P~
<Haohmaru>
i meant... a real one
<mawk>
like what, with a microcontroller doing it?
<Haohmaru>
yeah-ish
<mawk>
that would be the same thing as bitbanging it from a rpi, except infinitely more annoying and long to do
<mawk>
here I just grab a pi, find the right pins, install openocd, and press enter
<mawk>
the exposed GPIO pins on the pi are not decoration, they're for you to use them
<Haohmaru>
i'd think "bitbanging" on an MCU would be not as slow as on a MPU thru an OS
<mawk>
2MHz SWD isn't slow
<mawk>
and the pi's cpu is 1.5GHz
<mawk>
and there lots of ways to make it realtime so the kernel doesn't interfere
<mawk>
like with preempt-rt
<mawk>
you can even run baremetal code on the pi if you feel like it
<Haohmaru>
that'd be faster
<Haohmaru>
i mean, it must be
<Haohmaru>
2MHz SWD is... slow
<mawk>
it takes longer for the runner job to start and finish and process the data than the actual programming
<mawk>
program + verify takes a few seconds
<Haohmaru>
these 48MHz arm MCUs in the typical DAPLINKs i think do it faster, and they bitbang too
<mawk>
while it takes like a minute for gitlab to send the job
<mawk>
there's no point shaving off 2 seconds while you still have to wait for the rest
<Haohmaru>
oh well
<mawk>
and extra stuff is happening after that, connecting via USB to the device to check that the new firmware works
<mawk>
so now we have to bitbang SWD and we also have to be a USB host
<mawk>
that's becoming pretty complex to do on a MCU
<mawk>
and with the realtime linux patches there's almost no difference with a MCU, you have full control of the CPU
<mawk>
and the limiting factor for the speed is probably not the CPU but the super long cables I use to connect to the device
<mawk>
they're kinda big, I can't put them within 5cm of the pi
<mawk>
the flash of the device is 1MiB, you don't need to program it at 10GHz
<mawk>
and the most important of all, this is for a company, not personal project
<mawk>
the boss would never pay me for developing a custom SWD parallel thing
<Haohmaru>
use the Hammer >:)
<Haohmaru>
smash smash smash!
<mawk>
he might not authorize my next pay raise if I smash him lol
geep has joined #openocd
bryanb has joined #openocd
lh has joined #openocd
<Haohmaru>
wait, i meant "use the Hammer (the crapberry pie) to smash the SWD"
<PaulFertser>
mawk: there's also tcl/interface/dln-2-gpiod.cfg
<PaulFertser>
mawk: but yes, you're right, there's nothing like raspberrypi-sysfsgpio.cfg for libgpiod in upstream but it's easy to create.
<PaulFertser>
And you can use tools like "gpioget" and "gpioset" to probe the pins manually when needed.
<PaulFertser>
mawk: btw, there's kind of a catch, on certain platforms gpioset is only actively driving the pin while the userspace app is still running so when probing manually use something like "-m wait".
<mawk>
I see yeah
<mawk>
I tried to use pinctrl to see what openocd was doing but I was never able to catch it because it was too fast
<mawk>
also maybe you know PaulFertser because it says something about it in a comment in the raspberrypi-native.cfg file; some pins do not have the proper pullup on the pi?
<mawk>
there are some that have the regular 3.3V pullup that I need; but some that I measure at like 1.1V
<mawk>
even though I explicitly set it as input pullup with pinctrl
<mawk>
if I set it as output driving high it outputs 3.3V without problems
<mawk>
is thing a quirk of the pi, or did I just damage the pi
<mawk>
the pi is dead btw idk what I did, probably short one of the gpio to ground while it was driving high as I pressed the reset button manually on the device
<mawk>
ah nice, thanks!
<PaulFertser>
mawk: hm, well, while testing the -native driver I never had a problem because of lack of pull up or floating while OpenOCD wasn't running, probably that's not a problem in real life?
<mawk>
in the raspberrypi-gpio-connector.cfg file you see a comment about how SRST was moved to another pin because the previous pin didn't have pullup by default
<mawk>
and would cause devices to reset when openocd exited
<PaulFertser>
mawk: it talks about TMS/SWDIO though
<PaulFertser>
I see the comment and it's technically correct I guess but probably not too essential in practice.
<mawk>
ah yes it's about SWDIO
<mawk>
but for SRST it's kinda essential
<PaulFertser>
I mean OK, so TMS/SWDIO might be kinda unstable while OpenOCD is not running, but SCK is, so what. And once OpenOCD takes over the pin is driven properly.
<mawk>
yeah
<mawk>
I think the 1.1V pullup thing is a result of my obliteraring the pi, I can't find anything online
<mawk>
now it doesn't boot at all
<mawk>
it's either a short-circuit or ESD
<mawk>
for the short-circuit I'll make sure to only use open-drain reset config, and for the ESD I grounded the metal shelf on which they sit
<PaulFertser>
mawk: I see current code supports srst_open_drain, guess the code should be disabling pull-up/down for this configuration.
<mawk>
(through a 1MΩ resistor)
<PaulFertser>
mawk: you might still want to add like 47--100 in series for every data line for good measure.
<mawk>
well two pullups don't hurt
<mawk>
ah yeah good idea
<PaulFertser>
Better impedance match suppresses possible ringing plus current limiting to protect the boards.
<mawk>
if it disables pull-ups and uses open-drain for SWDIO/SWCLK why do we need to match impedance?
<mawk>
if it just makes it floating and relies on the stm32's own pull-up/pull-down for them
<PaulFertser>
mawk: RPi is driving strong with its CMOS outputs, giving steep edges, and the target might have its inputs really high-Z, so line inductance will lead to reflections and ringing.
<PaulFertser>
mawk: you're in a position to probe right near the target pin with an oscilloscope, right? So I suggest you do because with certain targets it was indeed problematic without at least some series termination.
<PaulFertser>
Not sure if it affects stm32 specifically or not.
<PaulFertser>
It would make sense if your targets supported JTAG, then you could have just chained them all.
<Haohmaru>
but he also wants to test them via USB something something
<mawk>
yeah USB is fine it's just a virtual com port
<mawk>
thanks PaulFertser I'll add them
<Haohmaru>
i use a custom SWD connector/port where i have a UART TXD/RXD on it too and conveniently the DAPLINK i use appears as a composite device with a built-in virtual-com-port, so it works nicely
<Haohmaru>
plug one thing and program and eyeball
<Haohmaru>
someone tell Arm if they happen to invent a new program/debug interface - make it less weird and at least make it easly work with some commonly existing peripheral like SPI ;P~
defiant has quit [Quit: defiant]
<mawk>
there's no uart on my device, it's just the usb com port
<mawk>
to make it easier for the production people to test it
JoseT has joined #openocd
Pokey has quit [Quit: Hecc! My server must have died!]