12:58 <lukego> Hey this morning I finally finished hand-soldering my Glasgow. I'm working on getting up the nerve to power it up now and see if it blows smoke :) I never assembled a PCB before. Any board-specific tips on how best to apply power from a bench supply, how much current would be good to start with, and what diagnostic tests to try before hooking up USB etc?

13:04 <tnt> You pretty much have to start at the nominal 5V (or 4.5V but not much lower) since the LM3880 will keep everything shutdown below 4.1V

13:05 <tnt> 100mA should be plenty for current limit.

13:06 <tnt> Might not be able to use OCP because of the large 150u bulk cap that will sink a current spike at power up ..

13:08 <lukego> Thanks! Really beginner question - how do I work out where to put power into the board? (supposing I'll use a bench supply rather than USB power)

13:09 <tnt> Just checked my rev c1 is at 28 mA on power up.

13:09 <lukego> Just find something that says GND and something that says 5V on the silkscreen or is that too simplistic?

13:09 <tnt> Well ... I have a female usb-a wired to banana plugs I use for those tests ...

13:10 <tnt> but you could solder wires to TP8 and TP12 and feed 5V there.

13:10 <tnt> actually TP13/TP14 is better.

13:24 <d1b2> <Attie> if you're nervous of shorts, then you can start with 5v and a low-ish current limit - tens of milliamps (but as @tnt says, don't trip on OC)... as you raise the current limit, the voltage should start to come up too (if it doesn't then you probably have a hard short somewhere)

13:26 <tnt> You can also just check for shorts before hand via the TP

13:26 <d1b2> <Attie> TP13 / TP14 are here (if you don't have the layout to hand)

13:26 <d1b2> <Attie> https://cdn.discordapp.com/attachments/613461005392936961/768102831806611476/unknown.png

13:27 <d1b2> <Attie> true - though that won't show up downstream shorts / high current conditions

13:36 <lukego> Thanks for the tips! I'm a serious beginner here so even terms like "test point" are only vaguely understood but I have google so a little nudge in the right direction goes a long way :)

13:37 <lukego> I have all the deets loaded up in KiCad but just not practiced at reading schematics yet

14:47 <lukego> I made a picture of the PCB and the internet has already identified at least one part that I goofed :) need a routine for checking orientations.https://drive.google.com/file/d/10imcKDcJVaMI8plnRcx3Tjf789ElwMMB/view?usp=sharing

14:47 <lukego> aside - is there any document explaining how to interpret Glasgow silkscreen? I've been kind of making educated guesses but sometimes I get confused/lazy while trying to concentrate on e.g. not putting too much hot air onto something that I already started

14:51 <tnt> U12 ?

14:55 <lukego> yeah. that thread is here fwiw https://www.eevblog.com/forum/beginners/first-pcb-assembled-how-to-start-debugging/

14:56 <lukego> also - I guess I'll also need to work out how to program the initial bitstream onto the board. I guess I'll find instructions on github? (if not then hints welcome because that's hopefully a step coming soon)

14:58 <tnt> No you don't.

14:58 <tnt> The fpga is loaded dynamically by the FX2

14:59 <tnt> and the FX2 has a ROM bootloader so its base firmware is also loaded dynamically.

14:59 <lukego> oh that's neat

14:59 <tnt> You need to load a serial number and some stuff in the eeprom. There is a 'factory' command in the CLI tool.

15:00 <tnt> `glasgow factory --rev C1`

15:00 <tnt> that should be pretty much all that's needed.

15:01 <tnt> then you can run the self test application.

15:03 <lukego> I'm looking forward to this :-) I actually don't know much about what Glasgow does to be honest... I just decided to get into electronics, and the board seemed about the same complexity as what I want to be able to make one day, and it seems like a tool that will be handy for making new boards, and it was right there on Github, so I just started learning to put one together and sooner or later it'll be time to RTFM :)

18:54 <whitequark> hey, can anyone sell me a glasgow?

18:54 <whitequark> well, my friend really

18:55 <whitequark> but i'll be the one buying

18:55 <whitequark> attie?

18:55 <whitequark> tnt: i think fx2 doesn't have a rom *bootloader*

18:55 <whitequark> i think it just has some hard logic

18:57 <thasti> y

18:57 <tnt> really ? you don't think it's some rom runnon on the 8051 at boot ?

19:03 <whitequark> tnt: it doesnt work just on boot...

19:03 <whitequark> you can poke xram in real time if you want even

19:03 <whitequark> concurrently with fw

19:03 <tnt> good point.

19:03 <whitequark> also the interface looks like hard logic

19:04 <whitequark> exactly 2 requests, very simple conditions, very simple function

19:25 <electronic_eel> strange why they went for hard logic. wouldn't it be much easier to load some simple data from a small rom into ram on reset?

19:29 <whitequark> electronic_eel: that might be how the EEPROM boot works

19:29 <whitequark> but the USB "boot" (really it's more like how a debugger works...) is a lot more reliable this way

19:30 <whitequark> the device is truly unbrickable so long as you don't disable USB

19:30 <electronic_eel> so you mean once the hard logic has detected that there is an eeprom with the correct signature, it loads stuff from a rom inside the fx2 to read the eeprom?

19:30 <whitequark> no no

19:30 <whitequark> the USB boot and the EEPROM boot are completely separate

19:30 <whitequark> i'm 95% sure the USB boot is hard logic

19:31 <whitequark> the EEPROM boot can be any traditional ROM boot, quite possibly is

19:32 <electronic_eel> ah, ok, so the whole sequence that checks the eeprom id and reads the eeprom is code from a internal rom

19:32 <whitequark> it *might*

19:32 <whitequark> i don't know for sure

19:33 <whitequark> the EEPROM sequence can override all xdata so it can't be xdata-mapped I think

19:33 <whitequark> so i don't know where the ROM would live in

19:33 <whitequark> since well

19:33 <whitequark> i guess it might have internally swap the code memory for the ROM without copying it anywhere?

19:34 <whitequark> thasti: was that a response to me or just a typo?

19:34 <thasti> whitequark: just a typo, sry

19:34 <tnt> The eeprom bootloader can only load 16k. you need a 2nd stage bootloader if you want all 64k loaded.

19:35 <electronic_eel> whitequark: don't you have the whole verilog source or something from the 8051 core used on the fx2?

19:35 <electronic_eel> maybe they have some bank swapping or some other logic for such a bootloader in there

19:37 <electronic_eel> tnt: so you mean they maybe put the bootloader rom somewhere above 16k?

19:38 <tnt> I honestly don't know the fx2 well enough to speculate. It was just a limitation of the bootloader that was noted in the app note I looked at 30min ago and that I thought might be relevant here.

22:12 <d1b2> <Attie> @whitequark is the friend EU/UK based? I have one left that is a little naughty, but likely fine in use.

22:15 <d1b2> <Attie> (I've been meaning to see if I can isolate the issue / rectify it)

22:59 <whitequark> attie: europe but not eu

23:00 <whitequark> electronic_eel: not the fx2, nrf24le1

23:00 <whitequark> attie: a little naughty is fine, i can debug it

23:00 <whitequark> electronic_eel: yeah, it's possible that the eeprom bootloader lives up there

23:07 <d1b2> <Attie> @whitequark - the "naughty" is a high impedance path between two pins - self test pins-ext shows as ~90% failure (neighbour follows driven pin)... It's ~50 MOhm IIRC (very hand wavey), so I wouldn't expect it to be an issue if you have any drive on it

23:07 <d1b2> <Attie> if that sounds okay, could I email you to continue the discussion?

23:38 <whitequark> attie: that's totally fine, pins-ext is just broken

23:38 <whitequark> yeah, please go ahead

23:39 <d1b2> <Attie> ah, interesting (it was the only board that exhibited the issue)

23:39 <d1b2> <Attie> i'll email now