00:12 <d1b2> <rwhitby> New addon for Glasgow under development - https://twitter.com/rwhitby/status/1361829828786229248 - looking for input from the experts here

08:12 <MadHacke1> gruetzkopf: Same. The later PICkits are particularly reflash-happy too, it seems like every chip never mind every family. :/

08:13 <MadHacker> That said, the programmer-on-the-go feature is great. I've used that really heavily in deployment on site in various weird places.

13:01 <_whitenotifier-5> [glasgow] whitequark closed pull request #275: cli: add --force-reload option to override bitstream id check in all cases - https://git.io/JtPFA

13:01 <_whitenotifier-5> [GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JtMzj

13:01 <_whitenotifier-5> [GlasgowEmbedded/glasgow] Tom Keddie 2689761 - hardware: always download a specified bitstream if the header is all ones

13:01 <_whitenotifier-5> [glasgow] whitequark commented on pull request #275: cli: add --force-reload option to override bitstream id check in all cases - https://git.io/JtMge

14:25 <d1b2> <Attie> @rwhitby you're supplying the LDO with 3.3v, and hoping for a 3.3v output too... this likely won't happen (depending on current draw... ds specs 170mV drop @ 300mA for Vout=3.3v)

14:29 <d1b2> <Attie> what are J8 / J9? they look like pin headers in the schematic, but seem to have a SOT-23-6 footprint & body... and are also not connected to anything?

14:36 <d1b2> <Attie> my USB-C knowledge isn't great, but the FUSB302B lists VDD typ as 3.3v... do you need / want 5v there?

14:38 <d1b2> <Attie> you might want to take a look at how @esden has handled the USB connector on the revC2+ boards - a thermal island might be useful for rework

14:40 <d1b2> <Attie> not sure what the plans are for A5-7, but a plated through hole might be nice - potentially to solder onto

14:56 <d1b2> <Attie> i also noticed that things like the M1 (which i think you're targeting here?) support interfaces like I2C on these pins... some ability to apply pull-ups may be good here? or do you expect the host / other end to provide these

14:56 <d1b2> <Attie> ... perhaps some PTH / pins again to allow something to be put in place if/when required

15:00 <d1b2> <Attie> the VIO selection looks reasonable, but I wonder if A) you need to be able to enable/disable these supplies, and B) might want to programatically alter the setpoints...

15:00 <d1b2> <Attie> (A can likely be addressed by tri-stating the IOs)

19:27 <electronic_eel> rwhitby: I had a look over your PD addon

19:28 <electronic_eel> I fear U2 (AP2171 power switch) will blow when VBUS goes above 5V. you should use something that can withstand 20V there

19:29 <electronic_eel> also connecting VBUS to the Vsense pin of glasgow will work fine on a revC2 and newer, but it will blow a revC1 and older

19:30 <electronic_eel> the older revs use a 3v3 ADC there with a voltage divider, not the INA233 that was introduced with revC2

19:31 <electronic_eel> "all jumpers out must be a safe voltage" is a good requirement from your readme

19:32 <electronic_eel> but when you change the supply of the AP2127 ldo to 5v (as attie suggested above), the output will go to nearly input rail when you disconnect all jumpers

19:33 <electronic_eel> you could add a basic voltage divider that is always connected and just tweak it with the jumpers. calculating the right resistances get's more complicated once, but I think this is worth it

19:34 <electronic_eel> you want to be able to use USB d+/d- and SBU1/2 as I2C, right? don't you need pullups for this to work?

19:36 <electronic_eel> how about adding a second usb-c connector to the board? this would allow to easily do PD sniffing between two devices

19:37 <electronic_eel> also wq isn't keen on maintaining a full luna stack for glasgow (see recently closed issue on github). so a usb host/device will usually be on some other device.

19:37 <electronic_eel> the second usb connector will easily allow to hook that up

19:42 <electronic_eel> A5, 6, 7 are currently unused, right?

19:43 <electronic_eel> you could hook up a i2c gpio extender there and use it to control the voltages, instead of the jumpers

19:44 <electronic_eel> if this is justified depends on how often you expect the required voltages to change and if it would improve usability of the whole addon

19:45 <electronic_eel> for example when you could make use of the second sense-pin of glasgow, you could reimplement the voltage mirror function the regular glasgow ports have

19:46 <electronic_eel> but this is of course a bit of feature creep and I don't know if you want that. so adding this is definitely not a must

19:47 <d1b2> <Attie> re dynamic control of I/O voltages... I was poking about in the Apple M1 bring up notes the other day, and it looks like the mode selected does influence the levels used

19:47 <d1b2> <Attie> so i'd recommend / suggest that is a good idea too

19:48 <d1b2> <Attie> (there is already an I2C bus on A0/A1 iirc...?)

19:48 <d1b2> <Attie> ... as i understand it, this is being put together largely to support the M1 work - is that correct?

19:48 <electronic_eel> ah, right, the i2c bus of the FUSB302, i totally forgot about that

19:48 <d1b2> <Attie> yep

19:49 <electronic_eel> yeah, the gpio extender could of course be hooked up there too

19:49 <d1b2> <Attie> and seconded re luna vs passthrough

19:49 <electronic_eel> just need to watch the vccs, as you already noted abov

19:53 <electronic_eel> you could also use a i2c controllable voltage divider instead of switching fixed resistors with a gpio extender. or a i2c dac with a similar setup as on glasgow

19:53 <d1b2> <Attie> judging by the response on twitter, this is a desirable addon!

19:58 <electronic_eel> replacing the jumpers with a small i2c dac would free up a lot of board space on the top. this is where the second usb connector could go

20:02 <electronic_eel> here was some talk about a Twinkie replacement, hardkrash mentioned some ics for protection against 20V: https://github.com/gregdavill/PD-sniffer/issues/5#issuecomment-766528992

20:03 <electronic_eel> they have the big downside of being only available in small-pitch WLCSP

20:04 <electronic_eel> but when developing with PD, I don't think it is unreasonable wanting to protect all lines against 20V

20:05 <electronic_eel> another idea: add testpoints for the CC lines. the user might want to hook up a scope there

20:11 <electronic_eel> re vbus on vsense of glasgow revC1: you could use a jumper for connecting it, as having this connection will be handy on a >=revC2. or maybe even a solderbridge you set once, depending on your glasgow rev

21:55 <d1b2> <rwhitby> Thanks everyone for your review and comments. I will respond to all of them in the next few hours. Do you prefer responses in this channel or #glasgow-addons?

21:58 <d1b2> <Attie> @rwhitby #glasgow-addons is 1b2 discord only... so here would be best (electronic_eel is IRC only for example)

21:59 <d1b2> <rwhitby> Do pictures posted on discord make it to the IRC mirror?

22:01 <d1b2> <Attie> pictures do, most other things don't play well (e.g: rtf, quoting, multi-line messages, etc...)

22:11 <d1b2> <NF6X> Do emoji make it to irc? 🤔

22:11 <d1b2> <Attie> https://freenode.irclog.whitequark.org/glasgow/2021-02-17

22:12 <d1b2> <NF6X> Yes, it made it through. Thank you!

22:27 <ebb> 🤠

22:33 <d1b2> <rwhitby> Yes, supplying LDO with 3.3V and expecting 3.3V out is ludicrous. What was I thinking?

22:34 <d1b2> <rwhitby> J8 and J9 are spare SOT23 footprints for soldering one whatever I forgot after the board is made. Is there a better way to do this in the schematic? If I just put down a footprint without a matching schematic symbol it gets deleted on schematic->layout updates.

22:35 <d1b2> <rwhitby> FUSB302B can take either 3.3V or 5V as VDD. I've chosen 5V because I need to run Port A at 5V to supply VBUS out in the DFP use case.

22:36 <d1b2> <rwhitby> Yes, I was considering just copying @esden's USB-C layout directly. Was waiting for functional stability before doing layout optimisation like that.

22:37 <d1b2> <rwhitby> A5 to A7 are spare 5V I/O. I put a bunch of vias there for soldering options - a full size pad used up too much space.

22:37 <d1b2> <rwhitby> (there are resistors there for pull-up or pull-down, with convenient vias for wiring that)

22:38 <d1b2> <rwhitby> With regard to M1 I2C options, it seems those are pulled-up on the M1, so no pull-up needed here. It is true that a depopulated pull-up resistor here may be useful if there is space.

22:40 <d1b2> <rwhitby> Regarding the VIO selection, after helping @marcan on his stream yesterday, I'm rethinking my VIO options. I may look at reducing it down to just a simple pass-through with no level shifters from Glasgow (which gets me everything I currently have except for 1.2V and solves the 3.3V->3.3V LDO problem), and then just support a fixed 1.2V level shifter (with dual resistors so that someone can replace resistors to chose a different voltage).

22:42 <d1b2> <rwhitby> Regarding U2 (AP2171) reverse voltage protection, I agree that it should be 20V tolerant, and I actually made this point in the stream yesterday for @marcan's board.

22:43 <electronic_eel> rwhitby: I just came back from having a walk outside. was thinking some more about the 2nd usb connector.

22:43 <d1b2> <rwhitby> Thanks for the input on the revC1 and earlier compatibility issues. A solder bridge that someone with revC1 and earlier can cut would be the appropriate thing here. We should assume that most people will have revC2 or later through the campaign purchase.

22:44 <electronic_eel> for the usecase of listening in to 2 usb devices talking pd or sbu, you probably want a second usb-c with all signals connected straight through

22:44 <d1b2> <rwhitby> I really want to avoid duplicating glasgow voltage control functionality - so perhaps a fixed 1.2V and pass-through options are best, and that frees up space for a second connector at the top.

22:44 <d1b2> <rwhitby> Yes, I was trying to convince @marcan to support pass-through on his board too.

22:45 <electronic_eel> how do you want to split off the signals for the 1.2 V thing?

22:45 <d1b2> <rwhitby> If I have room to add a second connector, I will definitely support sniffing of an existing connection and injection of messages into an existing connection, because that's a use case I have for my current proprietary board setup.

22:46 <electronic_eel> you'd still need the direction control to have the 1.2v level shifter option

22:46 <d1b2> <rwhitby> Yes, 1.2V level shifter still needs direction. it doesn't save any I/O pins on Port B.

22:48 <d1b2> <rwhitby> I did see the discussion about luna on glasgow, and understand not wanting to feature creep glasgow. I want to support glasgow/usb-pd and luna boards working together, because I don't think luna boards are going to support usb-pd.

22:52 <electronic_eel> back to my thoughts about the 2nd usb connector from above: the other usecase (instead of listening in) would be adding pd signalling to some other usb host or device, like luna

22:52 <electronic_eel> in this case you probably don't want the cc lines or sbu connected straight through, but just d+ and d-, correct?

22:53 <d1b2> <Attie> I'm going to be streaming more CAN work in ~7 mins, if anyone is interested... https://www.twitch.tv/attiegrande

22:53 <d1b2> <rwhitby> I had not seen the @Greg PD-sniffer project before, so will read through that, and the Twonkie design. I do have 2 x Twinkie myself (got them from Google engineers at an early-stage USB-PD interop workshop in Cambridge in 2014 (wow, I've been working on USB-PD now for over 7 years).

22:53 <electronic_eel> I'd even say you'd not connect vbus through, so you could command a device to supply 20v with pd, but still have your luna talk safely on d+-

22:54 <d1b2> <rwhitby> Test points for CC lines is a good idea. I did have vias there intentionally for that, but if I have room then full size test points are desirable.

22:54 <electronic_eel> so my idea was: why not have 3 usb connectors? two are straight through and the 3rd just has d+- through. vbus is supplied by an io from glasgow

22:55 <d1b2> <rwhitby> ok, that's the backlog response done.

22:55 <electronic_eel> @Attie: sorry, no time for stream today, will go to bed soon

22:56 <d1b2> <Attie> np!

22:57 <d1b2> <rwhitby> Regarding pass-through, my target use case is that I can snoop on SBU1/SBU2 and inject on CC1/CC2 and work with VBUS up to 20V. This is what's required for good USB4 development (excluding the data path - I doubt this board will be able to pass through the high speed lanes effectively to retain 40Gb/s throughput).

22:59 <electronic_eel> isn't it also relevant to just listen in on cc1/cc2, with the help of the FUSB302B?

22:59 <d1b2> <rwhitby> yes, injecting is a superset of snooping

23:00 <d1b2> <rwhitby> (you need to track the contract negotiation and alternate modes before you can safely inject)

23:00 <electronic_eel> ok, so these lines all need to be connected through, the signal integrety issues would make connecting ss through complicated

23:01 <electronic_eel> so I'd say ss lines are out of scope

23:06 <d1b2> <rwhitby> I have my own interposers which can tap off a pass-through SS connection, and I was talking to someone (I forget who) the other day about making some open hw replacements for those.

23:07 <d1b2> <rwhitby> (unfortunately proprietary, and only a handful were manufactured)

23:07 <d1b2> <rwhitby> https://cdn.discordapp.com/attachments/613461005392936961/811735488494829608/IMG_20210112_175922.jpg

23:07 <d1b2> <rwhitby> You can stack up to 6 of these in a TBT4 connection and make a stable 40Gb/s connection.

23:12 <electronic_eel> looking nice. but to get that i guess you need to properly engineer them. proper board stackup, optimize trace to connector pad layout and similar rf goodness

23:13 <d1b2> <Hardkrash> I like the 2.0 data pair routing resistors.

23:13 <electronic_eel> so not something you can have cheaply manufactured at jlcpcb

23:15 <d1b2> <Hardkrash> I imagine that the vendor azonenberg uses would suffice. Also the stackup might be cheaper than expected as it is used widely in cables.

23:15 <d1b2> <rwhitby> yeah, this was a well-known ODM that produced these for developing a well-known high-end VR headset.

23:16 <d1b2> <rwhitby> money no object 🙂

23:16 <d1b2> <rwhitby> it was my functional design, but everything after that was done by experts in their respective fields.

23:31 <rwhitby> @electronic_eel: I'll start reworking the level shifter stuff to make space for the second connector

23:48 <rwhitby> @electronic_eel: our design assumption for the level shifter LDO safety when all jumpers are removed is that a 10K R1 and an infinite (open) R2 would result in a 0.8V (Vref) output. A couple of people in the glasgow-addons channel looked at this. Are we mistaken?

23:58 <d1b2> <rwhitby> (I'm happy to be mistaken and learn something new 🙂