Stormwind_mobile has quit [Ping timeout: 240 seconds]
Stormwind_mobile has joined #glasgow
esden has quit [Ping timeout: 264 seconds]
eddyb[legacy] has quit [Ping timeout: 240 seconds]
eddyb[legacy] has joined #glasgow
esden has joined #glasgow
cr1901_modern has quit [Ping timeout: 260 seconds]
cr1901_modern has joined #glasgow
<d1b2>
<OmniTechnoMancer> What are the block things in the middle of the LVDS header?
Stormwind_mobile has quit [Remote host closed the connection]
electronic_eel_ has joined #glasgow
electronic_eel has quit [Ping timeout: 264 seconds]
_whitelogger has joined #glasgow
<d1b2>
<DX-MON> those are pick and place suction tabs
<d1b2>
<DX-MON> provides a big flat surface for the vacuum system of a P&P machine to heft it up from the tape and place it with
thaytan has quit [Ping timeout: 265 seconds]
thaytan has joined #glasgow
<d1b2>
<OmniTechnoMancer> Ah, I did wonder if it was that, thanks
Stormwind_mobile has joined #glasgow
electronic_eel_ has quit [Ping timeout: 264 seconds]
electronic_eel has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter_ is now known as PyroPeter
Getorix has quit [Read error: Connection reset by peer]
Getorix has joined #glasgow
Stormwind_mobile has quit [Remote host closed the connection]
umarcor has joined #glasgow
Stormwind_mobile has joined #glasgow
bvernoux has joined #glasgow
_whitelogger has joined #glasgow
<lukego>
okay let's have another look at this Glasgow board of mine and the soldering job on the voltage regulator
<lukego>
re: short on 1V2 rail, I'm measuring 3.2kOhm resistance between 1V2 test point and GND with the board powered off. High enough?
<electronic_eel>
lukego: resistance (measurement) is futile, with semiconductors in the loop at least ;)
<electronic_eel>
it is high enough that it is sure that you don't have a solder joint to ground
<lukego>
surely it would detect a short caused by e.g. PCB damage or a solder bridge?
<lukego>
ok
<lukego>
checking U36 now which IIUC is responsible for turning 1V2EN into 1V2+
<lukego>
oh, yes, this is badly soldered. I think that on inspection from above it looked fine because I thought the package had legs but it doesn't. fixing up...
<lukego>
Hey hey hey! D7-D10 are all lighting up on power from USB now :-). (D6 is faulty.) That's progress!
<lukego>
drawing 12mA
<tnt>
is 1v2 present ?
Stormwind_mobile has quit [Ping timeout: 268 seconds]
<lukego>
ype
<lukego>
yep
<lukego>
reckon I'll plug it into my laptop now and check dmesg. reasonable?
<electronic_eel>
yes, check if it enumerates
<d1b2>
<Attie> exciting!
<lukego>
right! but alas nothing reported in dmesg when I connect it, lights just come on
<whitequark>
fx2 not alive then
<whitequark>
(or in reset)
<lukego>
so I guess inspect soldering there, then check datasheet for things to probe with the scope?
<whitequark>
yeah
<lukego>
Soldering job looks pretty awful. I think that at some point I moved this chip while working with hot air and put it back pretty haphazardly. looks like I'll have to realign it but maybe get away with drag soldering down the sides
<electronic_eel>
you should be able to probe the reset of the fx2 on the reset controller, U7
<lukego>
I'll try drag soldering down the sides and then reflow the whole thing with hot air to realign if I see bridges/problems
<lukego>
actually I just did both. got some decent solder onto the joints then reflowed to let it realign. cooling now.
Stormwind_mobile has joined #glasgow
<whitequark>
having enough patience to let the board cool down... wow
<electronic_eel>
after enough burnmarks on your fingers you slowly begin to learn ;)
<whitequark>
electronic_eel: no, before plugging in
<lukego>
whitequark: if I'm honest I did sizzle some IPA while impatiently trying to clean up flux on the board while hot...
<whitequark>
ha
<whitequark>
IPA is so bad at removing flux in my experience. RMA flux anyway
<lukego>
yeah, I have really low confidence in IPA for this RMA gel flux. but a bit too impatient right now to bake the conductivity out of it or to wait five minutes on an ultrasonic bath
<lukego>
I should spend some time with the flux and a multimeter getting a better feel for its conductivity after the kind of work I usually do with it
<electronic_eel>
whitequark: to do the plugging in you need to touch it, that is where the still hot board burns my fingers
<whitequark>
electronic_eel: hm
<lukego>
I switched from one Amtech flux to another based on the rumour that it's easier to clean up between pins for drag soldering and there does seem to be some truth in that, but still
<lukego>
drawing 18mA from the bench supply now instead of 12mA. lets try the laptop test
<whitequark>
reliably removes RMA in any form with just nozzle pressure
<whitequark>
no scrubbing
<lukego>
thanks for the tip!
<whitequark>
note: there are tons of similar cleaners that have wildly varying composition
<electronic_eel>
lukego: I suggest to stick to Amtech (the true stuff, not the chineses knockoff), but use better flux cleaner instead
<lukego>
I'll also check out what's available from eleshop.eu. they're nearby and seem to do a decent job of only stocking stuff that basically works.
<whitequark>
look specifically for kerosene+isopropanol+ether in msds
<whitequark>
seems to be the magic combo that makes it work
<electronic_eel>
after whitequarks post on self-mixed flux removers i bought some raw chemicals to try mixing my own stuff. but i didn't get to it yet
<whitequark>
i know that pure aliphatic hydrocarbons don't do the trick
<whitequark>
electronic_eel: oh yeah, i couldn't find the pressurized bottle locally...
<electronic_eel>
i don't like the pressurized cans. the pressure gas goes out when the can is still half full
<whitequark>
electronic_eel: i mean the ones you can pressurize yourself
<whitequark>
it might have been someone else who recommended them to me, not you
<whitequark>
(i've never had factory pressurized cans do this to me fwiw)
<lukego>
I went nuclear and got an ultrasonic cleaner with a special flux removing solvent but that's more something to use after batch assembly rather than small touchups
<d1b2>
<OmniTechnoMancer> Distill some DCM out of paint stripper? 😛
<whitequark>
i can just buy DCM, and normally i'm more comfortable working with nasty shit than most people, but come *on*, DCM is just too toxic
<whitequark>
if i wanted to use a really nasty flux remover i'd use pure dimethoxymethane
<whitequark>
but ... why do it when kerosene with some additives works?
<electronic_eel>
the pressure cans won't help me much. i keep my stuff in a glass with a ground cap and drip it onto the pcb from there. then i use a brush
<whitequark>
electronic_eel: yeah, if you have patience for scrubbing, that'd help
<whitequark>
i rely on nozzle pressure instead
<whitequark>
lukego: FX2 still pretty dead
<electronic_eel>
hmm, without a bit of scrubbing and washing it off afterwards it wouldn't do much good i'd say
<lukego>
ok. I'll give it a bath and then try again.
<whitequark>
this board used to be filthy and covered in massive amounts of rosin
<whitequark>
there was no scrubbing, just sprayed it 2 or 3 times
<electronic_eel>
hmm, ok. if i spray my boards, you don't see much anymore, but it feels still greasy and sticky.
<whitequark>
yup, i've had other flux removers that were like that
<electronic_eel>
the grease has to go somewhere after all, it doesn't just vanish
<whitequark>
there is a reason i tell people to look for this specific formulation
<whitequark>
well, the liquid deposited by spraying drips down the board
<whitequark>
which is really why you need more than 1 time
<whitequark>
1st time, board is mostly clean but some remains of flux at edges
<whitequark>
2nd time, remove that too
<electronic_eel>
i got kerosene, IPA, methoxyproanol and orange terpene, maybe a bit of acetone. will try a mixture of these and see if it improves over the commercial flux remover i have now
<electronic_eel>
also a lot cheaper
<lukego>
okay still erroring in dmesg after correcting the soldering pretty thoroughly I think. time for some probery.
<lukego>
U7 pin #4 (CY_RESET) is steady at 3.2V. relevant to U1 issue?
<whitequark>
it's active low, so the reset is deasserted
<whitequark>
assuming 3.3V voltage rail is OK, I'd replace the FX2 with a known good one
<sorear>
why do we suspect a bad/damaged fx2 over all the other potential causes?
<lukego>
"known good" would be overstating it but I have a couple others I can salvage to try
<lukego>
(I'm okay with debugging by soldering, it is a bit more fun than probing)
<whitequark>
sorear: other causes such as what?
<whitequark>
fx2 doesn't need anything besides power to enumerate
<whitequark>
hm. power and oscillator
<d1b2>
<OmniTechnoMancer> I just think of that BGA chip that has been bodgewired onto a board
<sorear>
point.
<lukego>
okay replaced U1 and giving it another bath
<d1b2>
<OmniTechnoMancer> has the osc been checked?
<lukego>
no, maybe that's next
<whitequark>
I think it's not OSC because FX2 doesn't enumerate until the boot ROM runs
<whitequark>
i mean, doesn't activate the pull-up
<electronic_eel>
the most common soldering issue with qfns is too much solder on the exposed pad in my experience. it either lifts up the pins so they don't get a connection or oozes into the pin area and creates shorts there.
<electronic_eel>
i'd remove the fx2, use a desoldering braid on the exposed pad and solder it on again, without adding any extra solder on the ep
<lukego>
interesting. I can try that next. now I resoldered with a _lot_ of solder added around the exposed pads
<lukego>
oscillator is Y1 right?
<whitequark>
yes
<whitequark>
i second what electronic_eel said about QFNs
<whitequark>
(and would like to add that they are a *goddamn pain in the arse*)
<electronic_eel>
lukego: i meant the exposed pad in the middle, which is connected to ground, not the pads for the individual pins. adding enough solder on the outer pads is mandatory
<whitequark>
(seriously, reballing BGAs without a template is almost less frustrating than fixing badly soldered QFNs)
<electronic_eel>
some qfns have the wettable pads pulled up on the sides, they are much easier to work with than the ones that do not have that imo
<Yatekii>
o/
<whitequark>
Attie: btw, do you feel like converting any more applets to use nmigen instead of nmigen.compat?
<lukego>
this U1 seems to have pads on the sides elevated a bit. I splashed on solder to make those connect. there's also solder underneath though..
<lukego>
How do I check Y1 with the scope? I should see a high freq square wave?
<whitequark>
no
<whitequark>
definitely not square wave
<whitequark>
should be a 24 MHz sine or possibly truncated sine (I can poke my board to tell you for sure in a bit)
<tnt>
it's a crystal not an oscillator right ? Beware that your scope probe can actually kill the oscillation by its presence ...
<whitequark>
yes, but i just checked on my device and it's fine
<lukego>
which pin at what voltage / freq are you seeing?
<gruetzkopf>
the _absolutely horrible_ PLL in the SL811 locked, but not to 48MHz..
ExeciN has joined #glasgow
<d1b2>
<Attie> @whitequark yes, happy to take a look at converting some more applets - anything in particular you'd like to get attention?
<d1b2>
<Attie> " locked, but not to 48MHz " ... ouch 😦
<whitequark>
Attie: pretty much whatever you feel like working on
<whitequark>
there are some refactors that are necessary for wider adoption but are blocked on using nmigen
<whitequark>
e.g. IO refactor
<d1b2>
<Attie> ok - I might come asking when I'm ready to work on it.
<d1b2>
<Attie> need to finish up the freq counter too
<whitequark>
yup, feel free to ask, I'll guide you whenever you need
<d1b2>
<Attie> I've seen people saying "ack" - I presume as in "acknowledged"?
<d1b2>
<Attie> if so, ack!
<d1b2>
<Attie> (and thanks)
<whitequark>
yep, ack as in tcp/ip
<d1b2>
<0x53A> Hi all, I got my glasgow a few weeks ago but haven't yet had the time to play with it. On the github readme it says > Although first-class Windows support is an important goal and Glasgow already works on Windows, the installation process is not yet ready. and I've seen a discussion about python and USB drivers here in this channel a few days ago. Is there a short writeup somewhere about which files need to be dropped where? I'd be happy to fiddle with
<d1b2>
it a little bit, but I don't want to take up too much of your time, otherwise I'll probably just wait a bit.
<whitequark>
0x53A: in short: get the MSVC libusb for your Python version (ideally x64), put it *next to* python.exe (*not* in the DLLs folder)
<whitequark>
other than that you can `pip install -e glasgow/software` (basically just normal python package management) and it should all work as long as your device is flashed when it's first plugged in
<whitequark>
if it's not you'll need to use zadig to associate the winusb driver with it
<d1b2>
<0x53A> Thank you! I did python setup.py develop --user before I saw your second post, which also exited without any errors.
<electronic_eel>
0x53A: did you get yours from Attie? IIRC he didn't flash them before shipping bc he didn't know about this
<d1b2>
<0x53A> what is the glasgow entry point? For linux it says it copies a script to /usr/local/bin. How does it work for windows, is there a batch file somewhere?
<d1b2>
<0x53A> @electronic_eel yes
<d1b2>
<Attie> yeah - just about to say, if you did, share your SN and I'll let you know if you need to flash it.
<d1b2>
<Attie> (I flashed about half the boards)
<d1b2>
<0x53A> @Attie 20200924T010855Z
<d1b2>
<Attie> looks like you're in luck - it should have been flashed already
<d1b2>
<0x53A> thank you!
<electronic_eel>
0x53A: so you got your python running and are able to call pip? then it should install it somewhere in your user folder, i guess below appdata
<electronic_eel>
with install it i mean the glasgow sowftware
<d1b2>
<0x53A> I installed python 3.8 through the windows store and dropped the USB DLLs in the packages folder next to python.exe. Then I executed the setup.py, but I haven't really used python before tbh
<whitequark>
hm, you dropped USB DLLs there? plural? into the windows store folder?
<whitequark>
that seems... impossible, on multiple counts
<d1b2>
<0x53A> sorry, I copied the one dll to C:\Users\lr\AppData\Local\Microsoft\WindowsApps\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0
<whitequark>
yes. that's supposed to be a read-only mount...
<whitequark>
I suppose as long as it worked, it should suffice for our needs, but I have no idea *why* it worked
<whitequark>
ahh, ok, you only really needed the .dll. but the other files do no harm.
<d1b2>
<0x53A> aha, I found a glasgow.exe at C:\Users\lr\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\Scripts
<d1b2>
<0x53A> I already regret using the windows store version, but let's see what happens if I add that to the path
<d1b2>
<0x53A> Alright, calling glasgow fails with > FileNotFoundError: Could not find module 'libusb-1.0.dll' (or one of its dependencies). Try using the full path with constructor syntax. and it's probably due to some windows store weirdness.
<d1b2>
<0x53A> I just dropped the dll into C:\Windows\System32 ¯_(ツ)_/¯
<d1b2>
<0x53A> Now it works!
<d1b2>
<0x53A> thank you!
<d1b2>
<Attie> glasgow list should show your serial number
<d1b2>
<Attie> @whitequark did you see the image 0x53A shared? I've never done it / can't comment
<d1b2>
<Attie> (i think we established the IRC bridge brings images the other day, but just in case not)
<d1b2>
<0x53A> well, I tried a different cable on a different port and now it seems to work
<d1b2>
<Attie> oh, magic
<d1b2>
<Attie> well done
<d1b2>
<0x53A> okay, work in the sense that there was no error message, but glasgow list is empty
<d1b2>
<Attie> did device manager refresh / does it show the device?
<d1b2>
<0x53A> wait, I think this might be one of these "usb-charging" cables without data lines
<d1b2>
<0x53A> which would explain the "no error"
<d1b2>
<Attie> perhaps verify a cable with something else first
<d1b2>
<Attie> then try glasgow on a "known good" calbe
<d1b2>
<Attie> *cable
<d1b2>
<0x53A> known good cable on a known good port: > PS C:\Users\lr> glasgow list > Traceback (most recent call last): > File "C:\Users\lr\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\Scripts\glasgow-script.py", line 33, in <module> > sys.exit(load_entry_point('glasgow', 'console_scripts', 'glasgow')()) > File "c:\glasgow\repo\glasgow\software\glasgow\cli.py", line 828, in main >
<d1b2>
exit(loop.run_until_complete(_main())) > File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1776.0_x64qbz5n2kfra8p0\lib\asyncio\base_events.py", line 616, in run_until_complete > return future.result() > File "c:\glasgow\repo\glasgow\software\glasgow\cli.py", line 457, in _main > serial_list = GlasgowHardwareDevice.get_serial_list(firmware_filename) > File "c:\glasgow\repo\glasgow\software\glasgow\device\hardware.py", line
<d1b2>
120, in get_serial_list > handles = cls._enumerate_devices(usb_context, firmware_filename, _factory_rev) > File "c:\glasgow\repo\glasgow\software\glasgow\device\hardware.py", line 102, in _enumerate_devices > handle = device.open() > File "C:\Users\lr\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\site-packages\libusb1-1.8-py3.8.egg\usb1__init.py", line 2171, in open > File
<d1b2>
"C:\Users\lr\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\site-packages\libusb1-1.8-py3.8.egg\usb1__init.py", line 133, in mayRaiseUSBError > File "C:\Users\lr\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\local-packages\Python38\site-packages\libusb1-1.8-py3.8.egg\usb1__init.py", line 125, in raiseUSBError > usb1.USBErrorNotSupported: