<esden>
sorear: see the rest of the twitter thread ;) ... but yes both sides...
<esden>
it is a very long thread... I decided to go all the way in with live tweeting the process.
<esden>
marcan: it is very annoying, you use a different footprint than the one I use and bam all LED are reversed... >_<
<marcan>
esden: is the cap a larger footprint?
<marcan>
hey I used the standard LED footprint...
<esden>
no it is exactly the right footprint ... you designed a massive cap in there :P
<marcan>
I mean I couldn't find 330uF caps in the footprint I designed in
<esden>
it is taller than the one you designed in because I could not get a hold of one
<marcan>
ah
<marcan>
is it electrolytic or poly?
<esden>
it is from the exact same family of caps
<esden>
poly... I am still bit annoyed that the thing is in there at all to be honest... also it is too close to the SO8 part... it will be a problem when I try to pick and place it.
<esden>
and too close to the Cypress part as I will not be able to rework the qfn pads if something goes wrong...
<marcan>
I don't see any size E parts in that series at 330uF
<marcan>
with the right voltage
<esden>
marcan: it might be... that is not really the point ;)
<marcan>
what exactly did you put on there? :D
<marcan>
I'm pretty sure the cap you used is one size code too large
<marcan>
which explains why it's way too close to everything around it
<esden>
and even if the footprint is slightly smaller, it will be a total pain in the butt to get around that honker with a soldering iron ...
<marcan>
I specced E40 size and you probably used F61 or F80
<marcan>
so 6.3mm instead of 5mm
<marcan>
anyway, that cap is necessary, sorry :p
<esden>
>_<
<marcan>
esden: the soldering on those MG2040s looks good, glad I got that footprint right
<marcan>
that's the one I had to make from scratch
<esden>
yeah besides the TH mishap ;)
<marcan>
yeah yeah
<marcan>
:p
<marcan>
you're 1bitsquared right? so you can fix a 1bit error
<marcan>
:p
<esden>
that was seriously not a big deal I saw it was missing pretty quickly.
<esden>
marcan: ok I take it back... that cap is indeed a 6.5mm diameter... I know I also ordered the right diameter one for the build... this one somehow slipped in it seems.
<esden>
The other cap was also for glasgow as I could not get my hands on any of the caps that had the smaller footprint.
<esden>
Then I found the 180uF one on arrow. So I am reworking the boards and putting that one on.
<esden>
(I was just hoping to find lower cost source for the caps that is not arrow... the wider cap was all lcsc had to offer :D)
<esden>
(If I order a full reel and wait a few weeks I can probably get the exact part you specified)
<marcan>
esden: 180µF is fine
<marcan>
basically anything >=150uF >=6.3V poly in that footprint should be fine
<marcan>
esden: btw, either way don't bother with making any changes to Hana yourself since that footprint is generated from an SVG file with a converter that I have hacked up to break less (but it's still crap); whatever we decide to do I'll take care of that bit
<marcan>
tnt: just power decoupling
<marcan>
we need it to survive load transients, USB has terrible inductance
<marcan>
it's actually specified as required for the USB power limit switch we used, we just screwed up and didn't spec it for revC0
<sorear>
I forgot where Hana is from and it's a fairly common name
<ar>
esden: and this white + black + vibrant blue somehow reminds me of lego
<esden>
I plugged one into my computer. It seems to get VUSB but 5V is jumping up and down and not wanting to power on. But it is too late today to dig deeper into what is wrong... also I do not know exactly when I will be able to get back to it, probably after Teardown... :/
<esden>
ar: I really like the white and blue combination on the white board.
<esden>
it does indeed look like lego! That is probably why I like the look so much. :)
<esden>
(regarding the error, I might have populated something back to front ... who knows)
<marcan>
esden: checked the rails for shorts?
<esden>
yeah that was the first thing I did, and they seem all good
<marcan>
hm, and 5V (after the switch) is unstable?
<marcan>
does the PWR LED light at all?
<esden>
Ok I think the 3v3 regulator is in the 1v2 regulator spot
<marcan>
oof
<marcan>
that's.... not a great mistake to make
<marcan>
might've toasted the iCE40
<esden>
no shit...
<daveshah>
You would have got UltraScale-class timings for a couple of seconds though :P
<daveshah>
Although I wouldn't write off the iCE40 yet, it can be surprising how robust these things are
<marcan>
yeah, it might've survived, I've seen a PIC survive 12V
<daveshah>
I remember an ESP8266 surviving 5V on 3.3V for a couple of hours with no ill effects
<esden>
I swapped the regulators
<esden>
waiting for it to cool off
<esden>
ok it enumerates
<esden>
damn the green led is dim ;) ... but that is not a surprise with the massive resistor on it :D
<marcan>
esden: it's really not supposed to be that dim
<marcan>
are you sure you used the same LED?
<marcan>
it should be brighter than the user LEDs by default
<esden>
of course not... I used the ones I have in my inventory...
<marcan>
lol
<marcan>
then you need to adjust the resistor :p
<esden>
as I was saying I want to use as many parts as I have in my stock... you know that :P
<marcan>
sure, just saying then calibrating the resistors is up to you :p
<esden>
I know
<esden>
ok now really... good night :D
<marcan>
you can run the glasgow selftest to power up the user LEDs properly
<marcan>
by default they're just lit via the weak pull-ups which isn't representative
<esden>
ok, I installed an sdcc snapshot. That helped with the compilation. Now glasgow factory seems to look for the new glasgow VID:PID not the default Cypress one as far as I can see...
<marcan>
esden: it's supposed to look for the default one?
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<electronic_eel>
esden: maybe some device handle permissions problem?
futarisIRCcloud has joined #glasgow
electronic_eel has quit [Ping timeout: 272 seconds]
electronic_eel has joined #glasgow
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
uovo has joined #glasgow
oeuf has quit [Ping timeout: 268 seconds]
<esden>
marcan: I think I know why I had the voltage regulators reversed on the board. If I see it correctly the parts are reversed in the schematic. TLV75533 is a 3v3 regulator and TLV73312 is a 1v2 regulator.
<tnt>
esden: did you check the ice40 yet ? I just powered a up5k through its IO (just injection 3v3 into one fpga IO without any power rail present) and it booted just fine :p
<esden>
my `glasgow factory` still just says: `E: g.cli: device 20b7:9db1 not found` not sure what that is about... but the FX2 LED is now lit up... I guess my udev rules did not bite yet... I think I will restart my laptop... it is complaining about having a new kernel for a while now so it is time anyways. :)
<whitequark>
esden: let me check the factory code
<gruetzkopf>
what does lsusb say?
<gruetzkopf>
also: now that's a fun bug
<marcan>
esden: holy shit I'm an idiot. you're right.
<marcan>
I got that backwards a few times due to the "33" in 73312
<marcan>
need to fix that in the repo :/
<esden>
marcan: ;) happens to the best of us. No worries. As tnt says the ice40 is usually pretty robust. We will see very soon.
<marcan>
whitequark: should we overwrite the revC1 tag? this is a pretty stupid fuckup. I'm thinking I can put it on master, then cherry-pick that commit to fork off of the current revC1 and retag?
<marcan>
I'll do the swap such that the IC identifiers don't change, just the values
<esden>
(I really am not sure how I sould keep my modifications to the board... I wish there was a better way)
<marcan>
which means the only changes are fab layer and schematic
<tnt>
C0 also has the issue I'd guess ? Or did that part change between C0 and C1 ?
<marcan>
esden: yeah, we don't have a good story for that...
<marcan>
tnt: it did
<marcan>
C0 is fine
<tnt>
Ah yeah, it was a combined 1v2 + 3v3 reg
<marcan>
yup
<esden>
but for now it is more important that the schematic and fab layer are fixed.
<whitequark>
marcan: no retags, revC1 has existed for a while
<whitequark>
should probably be revC2
<marcan>
it's only a schematic change, PCB does not change
<marcan>
it's an errata
<marcan>
I don't think we want to revbump for this
<whitequark>
sigh
<marcan>
revC1.1 or whatever if you want another tag
<whitequark>
no
<whitequark>
just no
<whitequark>
this is basically gaslighting everyone who already cloned revC1
<whitequark>
(retagging that is)
<whitequark>
especially given that git will not update the tag on fetch if it exists locally
<esden>
But everyone who made the revC1 boards needs to be very loudly informed to make sure they populate the regulators in the correct order. :D
<marcan>
I hope that's basically you :D
<esden>
I wish there was an glasgow errata mailinglist like some vendors have.
<esden>
marcan: I am getting messages on twitter from 2 or 3 people now that ordered revC1 boards.
<marcan>
ah really
<whitequark>
I think it should just be C2.
<esden>
I will tweet about the mishap, hopefully these people will hear it and not make the same mistake I did. :)
<whitequark>
numbers are cheap, if we're up to revC35 then so be it.
<marcan>
whitequark: I really don't want to revbump the silkscreen for literally the exact same PCB
<marcan>
like 1:1 identical
<whitequark>
I don't see any other sane solution
<marcan>
also another set of output files?
<whitequark>
the old outputs can be renamed, like we don't have output files for revA
<marcan>
yes we do?
<whitequark>
oh
<marcan>
we already talked about using master for minor engineering changes like this; this falls squarely into that use case. the only problem here is the git tag.
<marcan>
maybe the tag should be a branch. that would solve the problem.
<whitequark>
I am absolutely opposed to ever replacing any git tags past (say) 5 minutes after publishing. after anyone could have fetched the tag.
<marcan>
yes, due to the practicalities
<whitequark>
as for other solutions, I don't know, and I feel too awful for unrelated reasons to make any sort of decision here
<marcan>
but we could just say revC1_p1 or whatever
<whitequark>
revC2 would do and I do not have any energy to work out a compromise besides that
<whitequark>
so it will have to wait an indefinite time until I do
<marcan>
ok, well I'll fix master for now
<marcan>
but really I think just tagging with a suffix should be fine
<marcan>
it's the same design
<marcan>
literally just swapping two labels in the BOM/assy layer, which we already agreed previously does not require a revbump
<marcan>
(we talked about this)
<marcan>
(we just never agreed on what to do about the tag)
<whitequark>
hm
<whitequark>
can we replace the tag with a branch?
<whitequark>
or will git do something insane in that case?
<marcan>
we can certainly make a branch, and they can coexist
<marcan>
because really it's refs/heads/foo and refs/tags/foo
<esden>
whitequark: which exact version of sdcc to use is probably what we should list in the documentation. Just installing the ubuntu package is way too old if one decides to use LTS :D
<marcan>
yeah
<marcan>
glasgow factory --rev C1
<marcan>
I think it just explodes if you don't pass a rev, that should be marked a required arg
<esden>
`glasgow factory: error: argument --rev: C1 is not a valid revision (should be one of: A0, B0, C0)`
<esden>
;)
<marcan>
lol
<whitequark>
pf of course, give me a second
<esden>
whitequark: FASTER :P ... (take your time I am just kidding)
<marcan>
esden: you can probably use C0 for now :p
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjaCk
<whitequark>
ah shit, we don't have the migen platform for c1 yet either
<marcan>
c1 should basically just be c0 minus the "shit's broken yo" warnings, for now
<marcan>
(later we'll mess with clkif/whatever too)
<whitequark>
marcan: i think the sync port changed.
<marcan>
somewhat
<marcan>
but we don't use it much yet so
<esden>
yeah no worries if flashed it using C0... is there a command to wipe it again? if I run factory now it complains it does not find the clean glasgow.
<marcan>
ah but since it'll look for the unprogrammed PID/VID, you need to short out the REC jumper (or the adjacent pins of the flash) while plugging it in
<esden>
marcan: it complains that it does not find the cypress device then ...
<electronic_eel>
ah, so vsense and vio crossed between the two ports
<marcan>
anyway, I need sleep, it's 5AM here :p
<electronic_eel>
marcan: good night
<esden>
marcan: have a good night, thanks for the help :)
<electronic_eel>
whitequark: so what is the purpose of the jig then when we have selftest and the loopback cable?
<electronic_eel>
is it just to save time connecting things?
<electronic_eel>
or also more analog tests, like voltage levels and exact current draw?
<whitequark>
electronic_eel: the loopback cable doesn't scale
<whitequark>
you need 1 second for a test and 10 seconds of fiddling with the cable to get it there
<whitequark>
and it will also break quickly
<whitequark>
neither the cable nor IDC connectors are nearly durable enough
<electronic_eel>
ok, so mostly speedup and durability
<electronic_eel>
the port headers - will they be soldered or not when the test is run?
<electronic_eel>
that makes a big difference when connecting pogo pins
<electronic_eel>
unsoldered is much easiers
<whitequark>
likely unsoldered
<electronic_eel>
...easier
<whitequark>
PTH is very expensive
<whitequark>
and we don't have other PTH parts
<electronic_eel>
very good
<electronic_eel>
esden: do you have any test fixtures or something like it you currently use for other boards?
<esden>
yeah it will be going out as a kit... "some soldering required" with additional service fee if one chooses to get the connectors pre-soldered.
<esden>
electronic_eel: I have to admit that I do not really have a jig... I started making one for 1bitsy ... but that ended up just being a jig that shorts all the pins to ground...
<whitequark>
wait what
<electronic_eel>
esden: was that intended for the test or some quirk in the design?
<esden>
it was meant as part of the test yes... I managed to basically do everything else as an internal test
<electronic_eel>
whitequark: if the purpose of the jig is primarily making connecting the pins faster & reliable - what do we need another glasgow as test runner for?
<electronic_eel>
I like to measure current in my tests, but that could also be done externally with a multimeter with remote interface
<electronic_eel>
esden: do you have a bench multimeter or a better handheld one with remote interface?
<esden>
I have a fluke 115
<esden>
nothing more fancy than that
<electronic_eel>
that doesn't look like it has any remote interface
<esden>
it has some magnetic managing accessory ... not sure how capable that is
<esden>
I would also get that... I might need to get a better multimeter with a remote interface ... :)
<tnt>
esden: definitely interested of your experience with those :
<esden>
electronic_eel: I personally would prefer getting one with the holes milled and pogopins already inserted. But yes getting a bare one is also an option.
<esden>
tnt: I bet you do. ;) ... no worries I will tweet up a storm about all this ... you know me :)
<whitequark>
esden: yes just talked about it before
<esden>
ok sorry
<whitequark>
that's the missing migen platform
<esden>
curious why it worked the previous time then...
<esden>
I did something differently I guess.
<whitequark>
i think you flashed C0?
<esden>
ohh right I flashed C0 replugged and then it worked... in the mean time I flashed C1 and kept going... after another replug it went to C1 and that is what made selftest complain
<esden>
all makes sense now
<esden>
I just went in history
<esden>
*I just went back in my terminal history to confirm
<esden>
ok I will stick to C0 for now so I can test things :)
futarisIRCcloud has joined #glasgow
<whitequark>
esden: C1 platform should work now
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+1/-0/±4] https://git.io/fjalI