whitequark changed the topic of #glasgow to: glasgow debug tool · code https://github.com/GlasgowEmbedded/Glasgow · logs https://freenode.irclog.whitequark.org/glasgow
_whitelogger has joined #glasgow
englishm has quit [Excess Flood]
englishm has joined #glasgow
englishm has quit [Excess Flood]
englishm has joined #glasgow
englishm has quit [Excess Flood]
englishm has joined #glasgow
englishm has quit [Excess Flood]
m4ssi has joined #glasgow
m4ssi has quit [Remote host closed the connection]
ali_as has quit [Ping timeout: 272 seconds]
ali_as has joined #glasgow
<electronic_eel> esden: ping
<electronic_eel> esden: could you please take a look at the schematics of my test jig board?
<electronic_eel> esden: I'd like to start with the layout
<tnt> electronic_eel: I know you didn't ask, but looks fine to me. It doesn't cover _every_ possible failure obviously, but success should result in a board that has a high probability of being good.
<tnt> Maybe the most annoying thing that's not really covered is a short on vbus/gnd of the DUT, that's just going to be passed directly to the rpi/sbc (hopefully it'll be able to detect it and not reboot).
<electronic_eel> tnt: thanks for reviewing
<electronic_eel> if the short is behind the usb power ic on the glasgow it will limit the current
<electronic_eel> just a short before the usb power ic will trigger the protection of the host
<tnt> I'm not sure if a rpi deals with that nicely (i.e. doesn't just reboot)
<electronic_eel> don't know either. the power and usb sections of the rpi aren't known for perfection...
<electronic_eel> there are two other things that aren't checked:
<electronic_eel> the leds, but esden said a visual inspection is ok
<electronic_eel> and the lvds io section
<electronic_eel> the lvds ios are on top and use a 1.27 pitch connector
<electronic_eel> so they are hard and finicky to connect to in a jig
<tnt> The ESD diodes aren't checked. Shorts will be detected but if one of the IO line isn't properly soldered to its maching ESD network, that won't be detected. There is unfortunately no easy way to test that ...
<electronic_eel> you are right. other similar stuff isn't checked too, like if the bulk polymer capacitor is soldered in or not
<electronic_eel> but to test stuff like this you'd need a full lcr test on each pin
<electronic_eel> IIRC there are ICs available from AD that do stuff like this, but I think it is a bit of overkill
<tnt> yeah sure.
<marcan> the esd diodes have capacitance that should be measurable
<marcan> I keep meaning to do that via a selftest thing
<tnt> marcan: I guess measuring the charge time through the pullups ?
<marcan> yeah
<tnt> 1pf through 10k is like t_rc ~ 10ns, that's pretty short.
<marcan> true
<marcan> sorth a shot though
<electronic_eel> the pullups are controlled via i2c - don't know if the jitter in controlling that is low enough
<electronic_eel> if we really want to test the esd diodes - wouldn't it be easier to apply like 7 or 8 v through a protection resistor and measure the current?
<tnt> I think the point was more, what can we do without any hw at all.
<electronic_eel> ok
<electronic_eel> the i2c jitter i talked about earlier - you could get around that by enabling the pullup all the time and setting the level shifter to output gnd
<electronic_eel> the switch the level shifter to input from the fpga - then you have precise timing from within the fpga
<whitequark> yep
jcreedon15 has quit [Ping timeout: 248 seconds]
ali_as has quit [Ping timeout: 245 seconds]