<whitequark[cis]>
<miek__[m]> "one problem i'm seeing is that..." <- no, there are no known issues, all i did was to change the frontend for the i2c gateware a bit
<whitequark[cis]>
miek__: thanks, can you check the PR one more time before i hit merge?
<miek__[m]>
lgtm!
q3k[cis] has joined #glasgow
<q3k[cis]>
Hm, I'm trying to use the swd-probe applet to explore some semi-documented ICs, but the applet throws a g.applet.interface.swd_probe: communication error. Tried to just use it with an RP2350 (Pi Pico 2, known working), same error.
<q3k[cis]>
Here's a logic analyzer trace, although when I run the LA in parallel with glasgow then the applet gets stuck, and on Ctrl-C I get a usb1.USBErrorNoMem: LIBUSB_ERROR_NO_MEM somewhere along the stack trace, so I'm not sure this is even a correct measurement.
Foxyloxy has quit [Read error: Connection reset by peer]
icanc[m] has quit [Quit: Idle timeout reached: 172800s]
puck has quit [Remote host closed the connection]
puck has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
esden[m] has quit [Quit: Idle timeout reached: 172800s]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
ih8c0ff33[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
@q3k there are no known issues with the SWD applet, but anyway, i'd like a full log and a savefile for analysis
<whitequark[cis]>
also, do i understand it right that the act of connecting your saleae in parallel breaks the applet?
<q3k[cis]>
Connecting and running, yes.
<q3k[cis]>
I assume some USB bandwidth contention issue.
<whitequark[cis]>
oh, no
<whitequark[cis]>
it's a dumbass linux thing
<whitequark[cis]>
it's helpfully preventing you from running out of DMA-low memory. for XHCI. because incompetence
<galibert[m]>
more lemmings
<whitequark[cis]>
there's a sysfs knob to remove the limit
<whitequark[cis]>
well, i mean you can raise it as far as it goes, it's totally artificial
<whitequark[cis]>
take a look at hardware/assembly.py, that has the exact path (i'm on mobile)
<q3k[cis]>
Yeah I've been there already before for unrelated reasons and have seen the comment block. I've just forgotten about it since.
redstarcomrade has quit [Read error: Connection reset by peer]
<q3k[cis]>
Anyway, how do I generate a 'savefile'?
<_whitenotifier-4>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-946-73a91184d5fd1c58d191e1cd7759497f31554165 - https://github.com/GlasgowEmbedded/glasgow
<q3k[cis]>
(I'm not ready to call this a Glasgow issue still, BTW - I'm still trying to reproduce things with other probes, targets, etc.)
<q3k[cis]>
(Wanna use this as an opportunity to both learn more about SWD and maybe contribute some Glasgow code. Just knowing that it should work is a good signal for me.)
<whitequark[cis]>
q3k[cis]: yes, this sounds great! the SWD applet is one of the very new ones and I think the code is quite clean and should be fairly reliable
<whitequark[cis]>
it also has simulation tests
<whitequark[cis]>
you can run your entire command set in simulation and load the VCD in saleae (probably) and check that it's not an electrical issue
<whitequark[cis]>
I did this a few times while developing and it's very helpful
<whitequark[cis]>
<q3k[cis]> "Anyway, how do I generate a '..." <- I mean hit ctrl+s in the LA
<q3k[cis]>
Qh!
<q3k[cis]>
*Ah!
<whitequark[cis]>
for glasgow, there is -L option
<q3k[cis]>
BTW, is there any plan to restore functionality to dump traces to VCD while glasgow applets are running? I think this could be useful for me here, at least so I can get rid of the logic analyzer from the debugging setup - as long as the trace VCDs could be trusted.
<q3k[cis]>
(or is this not how that feature worked?)
<whitequark[cis]>
this would be specifically very hard for the SWD applet because it uses DDR buffers
<q3k[cis]>
Ah, okay
<whitequark[cis]>
it's possible to capture and postprocess but it's very not trivial
<q3k[cis]>
Then it's fine, I'll stick to using the LA, I'll just have to invest a bit more time into my setup to make it easier for me to switch things around when needed.
<whitequark[cis]>
the feature predates the widespread use of IO buffers and Amaranth lib.io which it's not very compatible with
<whitequark[cis]>
so, one more thing you want to know about SWF
<whitequark[cis]>
s/SWF/SWD/
<whitequark[cis]>
it has three phases: command, status, and (sometimes) data
<whitequark[cis]>
most probes always blast enough cycles in a row to advance the DUT through all of them. glasgow is different, and will sometimes pause in the middle for flow control reasons. this can make traces look "weird" if you've only ever looked at like, stlink before
<whitequark[cis]>
(this is a part of what makes it the fastest probe supported by probe-rs)
<q3k[cis]>
Right, that's what I think confused me at first.
<q3k[cis]>
I set the frequency lower (100kHz, I think), just to get a 'pretty' trace and just in case I was hitting some weird edge cases in the targets I was trying to connect to, but I still couldn't get them to talk to me. Anyway, this is on me to debug further, I'll report back with my findings when I have some.
<tpw_rules>
oh i thought you were going to link the sd/mmc initialization sequence
<tpw_rules>
(as numbers of an OEIS sequence)
<q3k[cis]>
Ah, I figured out what was going on with my RP2350 SWD-from-Glasgow issues: it works only if I first run probe-rs info via a picoprobe first. If I then powercycle the target it doesn't work anymore. I'll gather some proper traces to support this.
<q3k[cis]>
* Ah, I think I figured out what was going on with my RP2350 SWD-from-Glasgow issues: it works only if I first run probe-rs info via a picoprobe first. If I then powercycle the target it doesn't work anymore. I'll gather some proper traces to support this.
<whitequark[cis]>
does it work if you do probe-rs via glasgow?
<whitequark[cis]>
i have just found an rp2350 in a box so i might try it out
<q3k[cis]>
whitequark[cis]: How do I do that?
<q3k[cis]>
whitequark[cis]: I can also give you a Pulseview session if you want
<q3k[cis]>
Ah no, now it works - I think this was because the picoprobe is not exactly fully disconnecting from the SWD bus when it's not active (for the issue I mentioned above though, I did verify with the picoprobe disconnected before and after the initial 'kickstart' to make sure that's not the problem, but I did still capture the trace with it connected, that's why there might be retries or other contention effects).
<whitequark[cis]>
<q3k[cis]> "swd-probe-rs or something :)" <- it will have a JTAG mode too in the future (it already has a multiplexing layer)
<whitequark[cis]>
i eventually decided to drop the protocol name from the bridge applets for the most part
<whitequark[cis]>
(the docs on the website should help locating applets)
<q3k[cis]>
<q3k[cis]> "Ah no, now it works - I think..." <- No, nevermind, this still seems quite flakey even with the picoprobe fully out of the loop by now.
<whitequark[cis]>
interesting. let me see if i can repro
<q3k[cis]>
Glasgow 276a4a52611cb21aeae68bb2e185bb1fcd925c6d, probe-rs a54f062f85a672f9007e35bedd3057e2dacb2dfd. RP2350 on a Pico 2 (non-W). Reproducible with the Glasgow connected directly to the SWD pins on the Pico. Pico is powered over USB.
<q3k[cis]>
Oh yeah the clock/data when controlled via probe-rs over the Glasgow look very unusual :)
<whitequark[cis]>
yeah, the unusualness is expected and desired, it's what lets me poll for WAIT without having to involve the host at all
<whitequark[cis]>
which should dramatically improve performance over slow links
<whitequark[cis]>
holdon, i only have a raspberry pi pico (unversioned)
<q3k[cis]>
Yeah, that's an RP2040
<q3k[cis]>
I think I can still do a nice repro pulse view session if you give me a few more minutes.
<whitequark[cis]>
yeah
<q3k[cis]>
I just have to fight my tools tooth and nail, including PulseView which crashes my logic analyzer after one capture.
<whitequark[cis]>
ok i ordered an rp2350 board with delivery in 13h