samlittlewood has quit [Ping timeout: 268 seconds]
samlittlewood has joined #glasgow
samlittlewood_ has joined #glasgow
samlittlewood has quit [Ping timeout: 265 seconds]
samlittlewood_ is now known as samlittlewood
_whitelogger has joined #glasgow
samlittlewood has quit [Ping timeout: 258 seconds]
samlittlewood has joined #glasgow
samlittlewood has quit [Ping timeout: 268 seconds]
samlittlewood_ has joined #glasgow
puck has quit [Read error: Connection reset by peer]
puckipedia has joined #glasgow
puckipedia is now known as puck
_whitelogger has joined #glasgow
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel_ has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
<lukego>
okay! let's see if we can identify these shorts in my Glasgow board. I don't have access to my full soldering setup today but multimeter is on hand. I'll check out the messages from yesterday and fire up Kicad and try to understand how the multimeter tests can distinguish between bridges on the connector side verses bridges on the FPGA side. Sounds like one will have a resistor in the path when probed on the connector
<lukego>
side that another won't.
<lukego>
aside: I'm surprised it took someone saying "IPA is useless for cleaning up tacky RMA flux" to make me realize the fact that has been completely staring me in the face for like a year.
<d1b2>
<edbordin> I've definitely seen other people say they avoid rma flux for hand assembly precisely because it causes shorts if not cleaned off thoroughly
<lukego>
I wonder if anyone has done some conductivity tests on the popular amtech RMA fluxes in different scenarios. I know that Amtech have tested and verified it as non-conductive but I assume that's after heating with a full-scale reflow profile.
<jpa->
there is always the scenario of "tiny ball of left over solder paste hanging on to flux residue"
<lukego>
So I'm told that I have shorts on A0/A1, A5/A6, B0/B1, B2/B3, and B6/B7. How do I lookup an ID like "A0" and identify which physical pin that is though?
<lukego>
jpa-: yeah that kind of thing worries me. I don't use solder paste and it's one of the reasons.
<jpa->
if you can find it on kicad schematic, you can use "show net" tool to see it on the PCB also
<lukego>
hm no I don't see it in the schematic even with the search function
<lukego>
I'm tempted to guess it's the pins labelled Z0..Z7 on the A/B connectors in the PCB layout
<lukego>
on that basis, with the board powered down, I'm seeing continuity (~1ohm) between B0/B1 only.
<d1b2>
<OmniTechnoMancer> Which test told you about these shorts?
<d1b2>
<OmniTechnoMancer> There was mention last night that the ext test was broken currently or something
<lukego>
pins-pull, pins-ext, pins-int all reported failures
<lukego>
... but all seem to have reported different combinations of pins as failing.
<lukego>
I really have two goals with Glasgow here. The immediate one is to assemble my first ever working PCB as a rite of passage. The other is to have a tool to use for debugging the first PCB that I design myself, which I haven't even started on yet. Question is whether I'm as close as I'm going to get to that first goal i.e. can I really identify and correct the hardware fault that I have now.
<lukego>
If the problem is under the FPGA BGA is doubtful because the soldermask there is damaged and I already soldered that part about as carefully as I'm able to. I don't think replacing it on this board is likely to yield a better result unless I would repair the soldermask first, which might be a fun project but I'll need to think about whether there's a suitable method available at this relatively fine patch with ~0.2mm
<lukego>
clearance between pad and exposed trace
<lukego>
If on the other hand I'm already as close as I'm reasonably going to get to making this particular board work then maybe I should just accept that, design a board of my own, and revisit the whole issue when I actually need a glasgow for working on that (maybe just assembling a new one in a reflow oven at that point or buying one off the shelf)
<jpa->
lasercut kapton tape can work for bga soldermask repair, but you'd need access to a laser cutter
<lukego>
but anyway, ranting aside, I'd really love any tips about how to isolate the fault to being under the BGA or not. I'm seeing unlimited resistance between the pins on the A/B connectors except for the rightmost two signal pins on the B connector which are short ~1ohm
<lukego>
Sounds advanced I guess to laser cut a stencil that would essentially cover the pads of the BGA (little isolated islands) and not the area in between? I guess you'd need to identify specifically where the mask needs to be repaired and "bridge" the pads with the remainder?
<jpa->
no, the opposite - the kapton tape would have tiny holes for the BGA pads, and you leave it in place under the BGA
<lukego>
ahh interesting idea!
<jpa->
but yeah, if multimeter measurements do not show a short-circuit between indicated pins, it could be that the test is not working or reports the fault on wrong pins for some reason
<lukego>
(I suppose my 0.2mm figure is off too, that'd be for reinforcing the soldermask between the pads and the exposed traces, when really it's supposed to cover those exposed traces.)
<jpa->
also i'm not sure if the tests might indicate error for not soldered pins also - that's a lot more common problem with BGAs than getting short-circuits
<lukego>
maybe I should try _doing_ something with the Glasgow rather than just running selftest. then maybe it could be found to be at least partially working (or not)
<lukego>
I've also carelessly melted these connectors so I'd really need to replace them anyway. actually I've ordered a vapor phase reflow oven and maybe the next step would be to just put the whole board into that with new connectors and see what happens. I could cover the BGA with tacky flux and hope that it seeps underneath to correct any unsoldered parts there but this might be optimistic.
<lukego>
(have to check if those connectors can handle 230C before trying that too...)
<tnt>
You can test the resistance between pins at each side of each resistor network. There is the "internal" part (before the voltage translators) and the "external" part (after the voltage translator) and then on eahc of theses, there are series resistor networks, each with 2 sides. For the first part you have the "toward bga" side and the "toward voltage tranlator" side. And for the second part yo uhave the "toward voltage translator" side and the "toward pins" side.
<tnt>
Measuring resistance between adjacent pins on thow 4 possibilities will tell you were the fault lies. High Z means no faut on that part. Lowish ( tens of ohms ) means short on that part but on the other side. Short ( < 1 ohm ) mean it's on that part/side, either on the resistor themselves or whatever they connect to.
electronic_eel_ is now known as electronic_eel
d_olex_ has quit [Read error: Connection reset by peer]
d_olex has joined #glasgow
<whitequark>
lukego: again, self-test WILL show false positive shorts between pins that are totally fine
<whitequark>
ignore it
<whitequark>
let me fix this upstream
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JTFE1
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark 711bfc4 - applet.internal.selftest: indicate pins-{int,ext} as broken on >=C0.
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JTFuE
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark 13a3509 - applet.internal.selftest: indicate pins-* as broken on >=C0.
<lukego>
whitequark: oh okay! I really hadn't gotten that message, thanks for stressing it. So what do I have to do to declare my board "kinda sorta more or less working"? :)
<lukego>
(just wait for the push I guess?)
* lukego
cools his jets
<whitequark>
lukego: i 'fixed' it upstream... in the sense that it no longer gives false positives
<whitequark>
anyway, until it's fixed properly, try doing something like
<whitequark>
`run uart --pin-rx=X --pin-tx Y tty` for every consecutive X,Y pair
<whitequark>
mh, no, that won't show all shorts
<d1b2>
<Attie> @lukego you mentioned you measured ~1ohm on a pin pair, and out-of-range on others?... focus on that 1ohm pair - there will be a short somewhere
<d1b2>
<Attie> follow @tnt's suggestion, testing before and after the level shift... if all others are high resistance (>100kOhm) then they are likely fine for use
<lukego>
thanks everybody for the tips. I'll give this a go when I'm back at the board ~tomorrow. I guess the main question on my mind is whether the FPGA is soldered correctly. I guess these tips are the best approaches we have to shed light on that? or should I be thinking about e.g. JTAG boundary scan?
<whitequark>
there's no JTAG in ice40 FPGAs
<d1b2>
<daveshah> no documented JTAG
<d1b2>
<daveshah> they definitely do have JTAG because some of the earliest SiliconBlue documents mention it
<d1b2>
<daveshah> not all the packages break out the relevant pins, and iirc those docs mentioned a SPI command (which they don't tell you) is needed to enable it
<d1b2>
<daveshah> the TRST_B on packages that had it became NC later on
<vup>
does it have a internal jtag primitive?
Getorix_ has quit [Ping timeout: 256 seconds]
Getorix has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 258 seconds]
<whitequark>
not a documented one
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Read error: Connection reset by peer]
Stormwind_mobile has joined #glasgow
<d1b2>
<daveshah> I haven't seen any evidence of one
<vup>
hmm
<d1b2>
<daveshah> I think there are probably some undocumented SPI commands, maybe one of those gives BS access
<ali_as>
Could it be TRST_B needs to be high on power up for it to function?
<whitequark>
that's how jtag works, yes
<whitequark>
er, sorry, on power up
<whitequark>
i misread
Stormwind_mobile has quit [Ping timeout: 268 seconds]
<ali_as>
The details on how to use Boundary scan were in TN1248.pdf until April 2013 but archive.org doesn't have it.
<ali_as>
I wonder if there is a bug they don't want to fix.
<d1b2>
<daveshah> or perhaps a security flaw in the NVCM readout protection they want to hide.....
<sorear>
the fpga is the least interesting chip on the board to do JTAG boundary scan on because you can as well do boundary scan with test bitstreams. do the FX2 and our pile of I/O chips do boundary scan?
<whitequark>
nothing on thta board has documented jtag
<whitequark>
which is why selftest exists
<lukego>
I feel like if selftest runs and produces a well-formed result then I can't have botched soldering the FPGA _too_ badly
<lukego>
the "level shifter" referenced above -- is that the resistor network under/over the expansion connector?
<tnt>
did you check like I described above ? (lik ... ~ 6h15 min ago)
<sorear>
the level shifters are the 8 6-pin chips between the FPGA and the resistor network
<lukego>
tnt: hey thanks! that suggestion came right as I was closing my laptop and context switching, missed it. next on my list now once I get back to my testing env ~tomorrow
Stormwind_mobile has joined #glasgow
lukego has quit [*.net *.split]
gillesmauve has quit [*.net *.split]
fridtjof[m] has quit [*.net *.split]
x56 has quit [*.net *.split]
lukego has joined #glasgow
x56 has joined #glasgow
gillesmauve has joined #glasgow
fridtjof[m] has joined #glasgow
gillesmauve has quit [Max SendQ exceeded]
fridtjof[m] has quit [Ping timeout: 246 seconds]
promach3 has quit [Ping timeout: 240 seconds]
disasm[m] has quit [Ping timeout: 244 seconds]
whitequark[m] has quit [Ping timeout: 240 seconds]
jevinskie[m] has quit [Ping timeout: 240 seconds]
jschievink has quit [Ping timeout: 244 seconds]
ZerataX has quit [Ping timeout: 244 seconds]
emily has quit [Ping timeout: 244 seconds]
bvernoux has joined #glasgow
whitequark[m] has joined #glasgow
jevinskie[m] has joined #glasgow
fridtjof[m] has joined #glasgow
whitequark[m] has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
fridtjof[m] has quit [Quit: Bridge terminating on SIGTERM]