<whitequark[cis]>
gsuberland: i was busy playing helldivers 2 so you will understand i think
<whitequark[cis]>
> For safety, do not connect Glasgow to a non-standards-compliant USB port with current capability exceeding 3.0 at 5V, as this may lead to permanent damage in the event of a fault.
<whitequark[cis]>
I'm reasonably sure we were protecting against that? lemme check
<whitequark[cis]>
but other than that, the format is great, you clearly have relevant experience doing something relevant that i can't yet quite place what it is, and writing up the results
<gsuberland>
there's OCP on the input switch IC (TPD3S014, U15) but if that shorts then the current path goes through FB1 which will immolate quickly with high current.
<gsuberland>
whitequark[cis]: day job involves lots of hardware RE and writing reports explaining how things are put together and how that results in a problem, so it's rather applicable to this kind of doc-writing :D
<gsuberland>
also yes I very much understand you enjoying helldivers 2, it looks a ton of fun
<gsuberland>
more than anything the "don't plug it into a thing that does >3A at 5V" was a suggestion based on the "instructions for safe use" card that's in the box
<whitequark[cis]>
I think it's valuable to describe both what we tell you to do, and which failure modes we think will happen and what'll result from them
<gsuberland>
yup
<whitequark[cis]>
because the inductor self-immolating to save the rest was, IIRC, deliberate
<whitequark[cis]>
bonus fuse
<gsuberland>
yeah
<whitequark[cis]>
and yeah TPD3S014 is actually fairly aggressive
<whitequark[cis]>
it's a protection IC for host ports, so your host has probably (... hopefully? at best?) something like that on its ports. quite possibly nothing
<whitequark[cis]>
> Fast Overcurrent Response – 2 μs
<whitequark[cis]>
ok yeah i do not see that being a problem in practice
<gsuberland>
yup. I'm mostly thinking weird powered hubs that do silly things like just throwing 5A at anything
<whitequark[cis]>
tbh enough bulk capacitance and you'll have that problem with anything
<gsuberland>
which is what I assume the card is referring to. 5V/3A is the spec, anything that offers more may do silly things and is generally just more hazard for no benefit
<gsuberland>
(in this context)
<whitequark[cis]>
I guess I don't want to scare people into thinking that they can't plug one into a power bank or something
<gsuberland>
cool, I'll explain the details then
<whitequark[cis]>
whereas in the absolute worst case the repair is gonna be like $1 plus rework time, which on a $200 device is completely appropriate
<gsuberland>
the 150uF is technically over USB spec but the TPD3S014 does soft-start so glasgow should never pull >850mA at any time
<gsuberland>
so that's fine
<whitequark[cis]>
yeah we did a bunch of testing to avoid tripping that, I think
<whitequark[cis]>
it was actually a real pain
<gsuberland>
yeah
<whitequark[cis]>
re: the supervisor, might want to expand how that should interact with downstream overcurrent conditions
<whitequark[cis]>
which is that (a) it should never droop below 4.5 or whatever it was volts that fucks up the FX2 but (b) if it somehow does we have threshold set up in such a way that it'll get into and out of reset reliably
<whitequark[cis]>
which, again, was a massive pain to tune
<whitequark[cis]>
for U2, might want to mention that X means it occupies two addresses
<gsuberland>
that's planned. I've already covered some of it in the power-on sequencing section I just finished writing, but I'll expand it and also link the github issue where the 150uF was added to fix the VIO short reset lockup
<whitequark[cis]>
great :3 thank you
<gsuberland>
whitequark[cis]: ah I had meant to ask you about the X, good to know
<whitequark[cis]>
yeah you can only get 512 kbit in one I2C address if you go for two byte addresses
<whitequark[cis]>
and i don't think anyone makes I2C EEPROMs with three byte addresses
<whitequark[cis]>
gsuberland: ok, here's an idea
<whitequark[cis]>
we deploy Thea Stargirl's kicad viewer on the website so that you can hotlink into the board
redstarcomrade has quit [Read error: Connection reset by peer]
<gsuberland>
I was thinking about that too :D
<whitequark[cis]>
kicanvas!
<whitequark[cis]>
i think the one thing i dislike about kicanvas is the controls, i want scroll to zoom, not pan vertically, and mouse3 drag to pan
<whitequark[cis]>
but that seems fixable
vegard_e[m] has joined #glasgow
<vegard_e[m]>
there's 1Mbit and 2Mbit I2C EEPROMs, but they're using the lower bits of the I2C address as the upper bits of the memory address, so they're still just 512kbit per I2C address
<whitequark[cis]>
vegard_e[m]: that's exactly what we're using
redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
notgull has joined #glasgow
Attie[m] has joined #glasgow
<Attie[m]>
Currently using Glasgow to generate a 50MHz signal, which is driving two Ethernet PHYs (RMII connected to an i.MX93)
<Attie[m]>
it produced a 100MHz signal nicely too...
<Attie[m]>
i'm pleasantly surprised that it's stable enough to handle data without toooooo many retries
<whitequark[cis]>
huh, nice
<whitequark[cis]>
the clock should be quite stable, around 20 ppm iirc
<Attie[m]>
yeah, it's doing well!
<Attie[m]>
considering my very poor handling of the signal too
<Attie[m]>
~95.1 Mbit/s over 100BASE-TX / RMII
<Attie[m]>
did a better job than my siggen which tops out at ~20 MHz 😂
<Attie[m]>
well that's made me happy - i've proven we can run the two Ethernet interfaces from a common clock, yay!
<whitequark[cis]>
nice
notgull has quit [Ping timeout: 240 seconds]
p1onk[m] has joined #glasgow
<p1onk[m]>
Just got my second glasgow, it seems to come up as "Another" interface explorer rather than as "Glasgow". I'm assuming that means the modified design flag is set. Any reason for that? If that was a mistake, is there any reason not to re-run `glasgow factory --reinitialize --rev C3 --serial $MY_SERIAL --manufacturer 1BitSquared --using-modified-design-files no`?
<p1onk[m]>
Second question: the FX2 LED seems awfully bright compared with the other LEDs, especially U3. Is that intended?
<whitequark[cis]>
p1onk[m]: esden made a mistake; there's a quirk for this in the repo so that no warning is shown, yeah. you can run that just fine
<whitequark[cis]>
p1onk[m]: U1..U3 are on pullups, the other LEDs are driven hard
<whitequark[cis]>
s/U3/U5/
<whitequark[cis]>
(the FPGA has pullups by default when in an unconfigured state)
<p1onk[m]>
Ok, it's light up my room bright, I wonder if there's something I can do to make it less annoying, like just PWM it.
<p1onk[m]>
Would measuring the resistance of the resistor next to the FX2 LED be more or less safe in-circuit with a multimeter, or should I desolder it first?
<p1onk[m]>
(That's R13 I believe)
<whitequark[cis]>
totally safe
<whitequark[cis]>
you can also uh, look at the schematic
<whitequark[cis]>
oh i guess you're comparing it
<whitequark[cis]>
btw try lighting up the LED with just the multimeter
<whitequark[cis]>
see how it's faring on maybe 100 nA or something
<p1onk[m]>
great, will do that tomorrow! Thanks!
<p1onk[m]>
Mostly want to make sure I don't hurt the FX2 driving current through PF2/FD10 while it's powered down.
<whitequark[cis]>
naw, the FX2 is made on a process from like early 2000s
<whitequark[cis]>
you could probably power it with 5V and it'll still survive mostly intact
<p1onk[m]>
nice
<whitequark[cis]>
I mean don't try that but
<whitequark[cis]>
it's old and sturdy
<whitequark[cis]>
it's not gonna object to like ten milliamps thru the ESD diode very much
<p1onk[m]>
I'll quote you if I do end up doing that
<whitequark[cis]>
lol sure :D
<p1onk[m]>
Hmm, the blue ICE LED is super faint by comparison
<gsuberland>
whitequark[cis]: I think I've got the docs to a good place for review, gonna call it for tonight :)
<whitequark[cis]>
lets see
<whitequark[cis]>
that is incredibly thorough, i'm honored to have your docs
<gsuberland>
^_^
<gsuberland>
there's a couple of todos in there I think. one regarding SYNC, the other regarding VIO on the subsheets
redstarcomrade has quit [Read error: Connection reset by peer]
ewenmcneill[m] has joined #glasgow
<ewenmcneill[m]>
gsuberland: I've had a read through your draft hardware docs, and it's an excellent description. Particularly for a test device like Glasgow it's very reassuring to have the safety logic of the hardware design so well documented.
<gsuberland>
ewenmcneill[m]: thanks :)
<gsuberland>
glad it's useful!
<whitequark[cis]>
yes, seconded
<gsuberland>
if I were to open up a PR, is hardware/boards/glasgow/revC3 a good place to put this document?
GNUmoon2 has quit [Ping timeout: 260 seconds]
<whitequark[cis]>
probably docs/manual
<whitequark[cis]>
it'd have to be in .rst though
<gsuberland>
haven't actually written .rst before, but looks pretty trivial to convert from markdown
GNUmoon2 has joined #glasgow
<gsuberland>
wow the table format for rst is truly horrible to work with >_<
<czero64[m]>
Hello, new user here. Does the Glasgow support differential signals, or only single ended? For example if I have an lvds uart, can I assign _p and _n pins via command line, or some other method?
<q3k[cis]>
<gsuberland> "wow the table format for rst..." <- it's so bad it's good
<q3k[cis]>
it's the lawful evil of markup languages
Foxyloxy_ has joined #glasgow
Foxyloxy has quit [Read error: Connection reset by peer]
<Attie[m]>
@czero64 - Glasgow does indeed have differential I/O, but they're not well protected, and haven't been used for much yet
fibmod has quit [Ping timeout: 252 seconds]
<omnitechnomancer>
It may be better to make a board with an LVDS receiver and transmitter on it with propper termination and then connect the resulting singled ended signals to the regular IOs?
<czero64[m]>
I have one of those board I'm trying to troubleshoot haha, I'm a newcomer to the field so the hardest part is figuring out where in the chain from source board to io board to io board output I'm having troubles
<czero64[m]>
s/board/boards/
<omnitechnomancer>
Do you have a multi channel scope?
<czero64[m]>
I do, that's how I've been investigating so far, I just got my Glasgow in the mail yesterday so I was looking for an excuse to play with it
<Attie[m]>
🥳
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
<esden[m]>
I wrote a bit of a data analysis tool. If anyone here wants to know where they are in the Glasgow campaign fulfillment queue, let me know. I need your order number and I can look it up now. 😄
<galibert[m]>
you're making me curious, 177877
<esden[m]>
Of course it is an estimate. I can not guarantee that the order I picked for the order fulfillment is exactly the same as the one Mouser will use. But so far it seems "close enough"