<Jonimus>
I'm trying to use my glasgow as a logic analyzer to log/RE an SPI interface but it imediately gives me a FIFO overrun error what does this mean and is there anything I can do about it?
<Jonimus>
I'm trying to RE a device using a CC2500 rf chip that should be similar to the nrf24l01 device that is one of the example applets.
<Jonimus>
If there is a way to say just log this SPI connection that would work as well. If this is not easily possible I have an older bus priate I could try but I'm not sure that is going to be fast enough.
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #glasgow
<Darius>
Jonimus: what have you tried? eg what command line
<Jonimus>
glasgow.exe run analyzer --port A --pins-i 1,2,3,4 -V 3.3 test.vcd
<whitequark[cis]>
the analyzer applet has a number of issues that make it not very usable, it's something i'd like to improve but haven't got around to
<whitequark[cis]>
enabling pullups or pulldowns might help if the cause is a floating pin that produces spurious transitions
<Jonimus>
same results of FIFO overrun, shutting down
<whitequark[cis]>
can you upload the resulting VCD?
FFY00_ has quit [Read error: Connection reset by peer]
<Jonimus>
Yes, I could get linux if absolutely needed but it would be a bit.
<Jonimus>
Actually I think my options for linux with a usb3 interface are limited at the moment because my install broke on my laptop and I haven't fixed it yet...
<whitequark[cis]>
I'm getting a different error on Linux, let me fix that and if it doesn't do the trick I'll grab a Windows machine
<whitequark[cis]>
okay, I think there are actually two bugs here
<Jonimus>
If not I can deal, I was able to pick of a sigrok compatible fx2 board that'll be here sunday, though I'd obviously rather use my fancy glasgow thanks to your awesome work.
<whitequark[cis]>
we should be able to get this sorted within a hour
<whitequark[cis]>
okay, so the first problem is that line 615 should say `if config.getNumInterfaces() <= self._iface_count:`
<whitequark[cis]>
and the other I'll just submit as a PR
<whitequark[cis]>
okay, new applet API is done I think
<Jonimus>
I'm still getting FIFO errors after not too long, but I'm also new at any sort of RE work like this so I'm not sure how to turn this into the bytes being sent via spi, but its definitely something.
<whitequark[cis]>
you could use pulseview... it's somewhat nightmarish to install on windows though
<whitequark[cis]>
if you give me half a hour I should be able to make a dedicated SPI sniffer applet
<Jonimus>
I'll look into that, if it'll run on WSL that migth work.
<whitequark[cis]>
it miiiight run on WSL, but it's also incredibly janky software
<_whitenotifier-5>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-813-9df30cdf82a8cf1ece7dba6975582589e806209e - https://github.com/GlasgowEmbedded/glasgow
<Jonimus>
It appears to be doing something, but the bits I'm interested seem to be scrolled out of my terminals buffer before I can grab them, how hard would it be to save that to a file?
<whitequark[cis]>
what should the format be?
<whitequark[cis]>
i guess just pairs of hex numbers
<Jonimus>
Heck if there was a way to get the debug output you have that'd be fine. I'm just trying to see what chip init looks like and then what the output looks like from there.
<Jonimus>
Which supports the nrf24l01/p, the cc2500 and 3 other similar chips all in one package. But the protcol support is is currently either ship the hardware to the dev or try to get dumps of the spi comms for them to work from.
<Jonimus>
Well I was able to confirm a good bit of what I wanted already on the cheaper TX I have, I'll have to do the same setup to my nicer TX and see if the one that actually receives telemetry does anything different though I suspect not but that was the goal.
<whitequark[cis]>
nice
<Jonimus>
thanks again for the help I'm gonna try to get some sleep and play some more in the morning. If this goes well I'll be trying this on a nrf based unit as well to double check that it matches what the project has documented and be looking into if there are more things I can add.
<whitequark[cis]>
you're welcome!
<whitequark[cis]>
i'm going to fiddle with this thing a bit more, it seems to not handle overflows that well when paired with a fast SPI device (SD card here)
<whitequark[cis]>
oh, it's because this device polls the SD card at 27 MHz (the applet is only supposed to work at 24 MHz...)
<whitequark[cis]>
so, the SPI analyzer works basically fine with slow SCKs, but I'm not happy with it
<whitequark[cis]>
i think sampling the SPI from the system clock (48 MHz in our case) is very limiting: you can sniff at most 24 MHz SPI signals, but realistically it's less than that, especially if we're talking about dense, back-to-back transfers
<whitequark[cis]>
i could always make a faster clock domain, but it would still be limiting, just somewhat less so
<_whitenotifier-5>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-818-5cedb3105b962db00f0fbc7403964c7ad751f03c - https://github.com/GlasgowEmbedded/glasgow
<whitequark[cis]>
of course, i could always make a clock domain driven by SCK. but the problem in that case is: what happens once you raise CS#? you might no longer have any clock cycles, and so you wouldn't have any good way to push the "this is the end of the packet" message into the FIFO
<Wanda[cis]>
clearly you need DDR clocking and a clock XOR
<whitequark[cis]>
the clock mux is a 4-input, 1-output function which fits into a single LUT and with care applied to the truth table it could be made glitchless
<Wanda[cis]>
are you going to use the whole circuit as-is, with the flops?
<whitequark[cis]>
yeah
<Wanda[cis]>
it has a problem: switching away from a stopped clock does not work
<whitequark[cis]>
oh right. i thought for some reason that switching away from a clock that is high does not work
<whitequark[cis]>
but you are right
<Wanda[cis]>
could always do some async design crimes
<whitequark[cis]>
my headmate suggests not doing any of it but rather add a 1 bit resetless register that gets flipped for the first byte that is clocked into the FIFO on SPI side
<whitequark[cis]>
s/it/this/
<whitequark[cis]>
then on the other side, every time this flag flips polarity, it means there was a gap in CS#
<whitequark[cis]>
and the SPI state machine in this case would be reset on CS#. provided there is no hold time violation between SCK and CS# i think this will work?
<whitequark[cis]>
(and if there is, i guess it chews off one last byte, which isn't too bad; or CS# could be delayed via LUT crimes)
<whitequark[cis]>
i want this applet to work at least up to 65 MHz which is roughly where ECP5, Xilinx, and Intel flash SCK is
<whitequark[cis]>
130 MHz would be ideal but probably pointless without HyperRAM
<whitequark[cis]>
<whitequark[cis]> "my headmate suggests not doing..." <- ie if the register is 0 on reset, clock the first byte with 1 and flip it to 1 at the 8th SCK edge; this avoids transactions being glued together if someone clocks in only a few cycles and abandons a transaction
<whitequark[cis]>
* ie if the register is 0 on reset, clock in the first pair of bytes with flag set to 1 and flip the register to 1 at the 8th SCK edge; this avoids transactions being glued together if someone clocks in only a few cycles and abandons a transaction
<whitequark[cis]>
i can't actually think of any async crimes that would make this work given the very few constraints on SCK and CS#
Eli2 has joined #glasgow
ali_as has joined #glasgow
<whitequark[cis]>
asjackson: so, all of the changes i was talking about to the applet system have landed in `main`
<whitequark[cis]>
if you update your applet to use them (see the UART applet or the boilerplate example code) you will be able to instantiate two GPIB applets talking to each other easily
<asjackson>
awesome stuff whitequark[cis] :) i will hopefully look at updating the bits tomorrow or monday
<whitequark[cis]>
cool!
jfsimon has joined #glasgow
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #glasgow
<whitequark[cis]>
<whitequark[cis]> "my headmate suggests not doing..." <- it works in simulation
<whitequark[cis]>
once again i'm incredibly pleased with how easy it is to set up simulations for applet components with amaranth 0.5
<whitequark[cis]>
historically i just didn't bother doing this because it was pure suffering, not anymore though
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #glasgow
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #glasgow
dustinm`_ has joined #glasgow
<whitequark[cis]>
hm, now that i'm testing it, it doesn't work very well at 24M
<whitequark[cis]>
but i'm not sure if it's the analyzer or the wiring or the signal source or what else
<whitequark[cis]>
looks to be at least partly due to how the qspi-controller applet works
<whitequark[cis]>
yeah, after improving the wiring and adding a delay before deassertion and after reassertion of CS#, it works a lot better
<whitequark[cis]>
not entirely clear what's going on, either a timing violation or just a signal integrity issue (i feel like it's probably the latter?)
Attie[m] has joined #glasgow
<Attie[m]>
oh, this reminds me... I was trying to interface with an SPI device a while back, and it has fairly substantial timing requirements from asserting CS, to the first clock edge.
<Attie[m]>
frustratingly I don't remember what it was now, and I wasn't in a position to tinker with Glasgow to get it working
<Attie[m]>
(it was a pressured day on site with a customer...)
<whitequark[cis]>
i think it's mostly signal integrity issues more so than design issues with the applet... at least thus far