<d1b2>
<rwhitby> oops, have my zone priorities reversed.
egg|anbo|egg_ has joined #glasgow
evck_ has quit []
<d1b2>
<rwhitby> To be honest, I'm not really happy filling the power rails.
<d1b2>
<timonsku> noob question, I want to dump a flash chip with Glasgow. The identify command tells me I got 32Mbit flash. Now if I want to dump the whole thing am I correct when I specify the address range 0 0x3D0900 ? 0x3D0900 being 4000000 bytes = 32 Mbits
<d1b2>
<DX-MON> as it's Flash, I'd expect you want 32Mibibits
<d1b2>
<timonsku> 25 series flash to be exact, not something more weird
<d1b2>
<DX-MON> 4194304 bytes (0x400000)
<d1b2>
<DX-MON> that's almost certainly power of two M rather than SI M
<ebb>
^
<d1b2>
<Attie> yeah, I was just about to say the same thing
<d1b2>
<timonsku> ah ok
<ebb>
Things change on SSDs where they are loading it with flash chips
<d1b2>
<DX-MON> I strongly dislike manufacturers insisting on getting this wrong
<d1b2>
<Attie> Mib / MiB != Mb / MB
<ebb>
But your single flash IC, always powers of 2 :)
<d1b2>
<Darius> mass storage land is a magical place
<d1b2>
<DX-MON> @Darius the one full of lies and marketing guff?
<d1b2>
<timonsku> so that SFDP table output is lying to me? 😄
<d1b2>
<Darius> yeah that's it 🙂
<d1b2>
<DX-MON> sounds like we maybe need to check Glasgow's reporting units there too
<d1b2>
<DX-MON> make sure they say Mib for Mebibits
<d1b2>
<timonsku> sure that makes sense, its just that the Glasgow print out says Mbits specifically when telling the size 🙂
<d1b2>
<DX-MON> this is the memory-flash applet?
<d1b2>
<timonsku> yea
<d1b2>
<timonsku> or wait
<d1b2>
<timonsku> "memory-25x"
<d1b2>
<Attie> yeah ... that's a common whoopsie when it comes to tech unfortunately... when you see MB, it typically actually means MiB, unless you're looking at a spinning disk
<d1b2>
<timonsku> I guess in that case the language should probably be adjusted in the applet
<d1b2>
<Attie> yeah, sounds like @DX-MON is digging
<d1b2>
<DX-MON> looks like it's the SFDP table that's got the error in it
<d1b2>
<rwhitby> (GND plane is unbroken on another layer)
<d1b2>
<DX-MON> I'm not sure.. but the latter will get you far better noise immunity and reduce the need for additional decoupling due to the area effect
<d1b2>
<DX-MON> I'd very honestly go with the power plane
<d1b2>
<rwhitby> so there's no downside to that huge chunk of 5V rail?
<d1b2>
<DX-MON> nope
<d1b2>
<DX-MON> and I'll double on that as it's an inner layer, so with the pour missing, you'll only be causing the manufacturer to likely insert floating copper pads to aid the manufacturing process and prevent voiding
<d1b2>
<DX-MON> ie, the pour helps make it more manufacturable
<d1b2>
<rwhitby> should I increase clearances on the pour or something?
<d1b2>
<DX-MON> you can if you want
<d1b2>
<DX-MON> what are they set to atm?
<d1b2>
<rwhitby> currently it's set to 0.2,,
<d1b2>
<rwhitby> mm
<_whitenotifier-5>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/Jt5ZO
<_whitenotifier-5>
[glasgow] whitequark closed pull request #277: Clarify the wording of the Flash sizes listed by the SFDP decoder - https://git.io/Jt5Zv
<d1b2>
<DX-MON> I might go so far as 0.4mm then but not larger
<d1b2>
<konsgn[no-Mic]> inner layers also carry less current per deg c rise in temp, so plane is better
<d1b2>
<DX-MON> this too
<d1b2>
<rwhitby> 4mm "feels" better to me. maybe I'm just scared of stuff shorting out on inside layers, having never done a 4 layer board before.
<d1b2>
<konsgn[no-Mic]> do you guys really use metric for all such distances, I've always found mils to be an easier reference?
<d1b2>
<DX-MON> this girl definitely does.. thou is.. confusing
<d1b2>
<DX-MON> and yes, I will say thou as "mils" is too close to the short pronunciation for mm and deprecated
<d1b2>
<konsgn[no-Mic]> find myself constantly jumping between mm to define board layout and mils for all spacings/sizes. 6mil 5 mil , nice small round numbers
<d1b2>
<DX-MON> this is one of the inner layers for SPIFlashProgrammer
<d1b2>
<DX-MON> I have had this board fabed by JLC, and all 5 units came back correctly
<d1b2>
<rwhitby> (should we move this to #pcb or something - apologies for starting this in here)
<d1b2>
<rwhitby> If anyone has any aesthetic comments on the USB-PD board, I'm ready to take those now too 🙂
<d1b2>
<DX-MON> (ah, probably)
fridtjof[m] has quit [Quit: authenticating]
fridtjof[m] has joined #glasgow
balrog has quit [Quit: Bye]
<d1b2>
<rwhitby> I'm going to grunt chat stream the board layout now, so if anyone wants to critique it please jump on and tell me what I'm doing wrong.
balrog has joined #glasgow
egg|anbo|egg_ has quit [Remote host closed the connection]
sknebel has quit [Ping timeout: 246 seconds]
sknebel has joined #glasgow
d_olex has quit [Remote host closed the connection]
d_olex has joined #glasgow
d_olex has quit [Ping timeout: 240 seconds]
<d1b2>
<konsgn[no-Mic]> what is the function of the fx2/ice i2c eeprom?
<d1b2>
<Greg> The firmware for the FX2 is stored there. And also there is room to have a bitstream on-device, so potentially glasgow could preconfigure itself with a pre-loaded bitstream when it's plugged in. Instead of waiting until the glasgow software is run.
<d1b2>
<konsgn[no-Mic]> hmm, so the fx2 doesn't get firmware pushed through usb? also, the ice40 i2c doesn't get read by the fpga, but rather by the fx2 which would then push it to the ice40?
sknebel has quit [Quit: sknebel]
sknebel has joined #glasgow
<d1b2>
<Greg> I think you're right, the main firmware is loaded via USB. But some config data VID/PID, serial numbers etc. are stored in EEPROM.
<d1b2>
<konsgn[no-Mic]> ahhhhh, gotcha, like the ftdi devices too
<d1b2>
<Greg> The software needs to know it's talking with a glasgow hardware and not just a blank FX2 chip.
<d1b2>
<konsgn[no-Mic]> makes sense.
<d1b2>
<Greg> In the software glasgow.cli has a function for performing a 'factory' programming of a new device. That shows what info is loaded into the EEPROM currently.
<d1b2>
<konsgn[no-Mic]> Very cool, Thanks!
<d1b2>
<rwhitby> ok, I think I've got the power planes sorted for USB-PD on Glasgow. Nice disjoint regions 🙂
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #glasgow
<d1b2>
<konsgn[no-Mic]> I don't think it's possible in kicad yet, but I like putting rounded edges on the powerplanes. Don't think it really helps much, but it gives me a warm feeling.
<d1b2>
<konsgn[no-Mic]> I don't think you have any large current paths through the board, but keep in mind smaller vias don't work great for higher currents. I've also heard that having multiple vias per supply pin help reduce inductance... not sure if/ how much that's true though.
<d1b2>
<DX-MON> you can tell KiCad 5 to use Fillet corner smoothing and set the radius (I personally use 0.2mm, but more gives more rounding)
<d1b2>
<konsgn[no-Mic]> oooh nice! seems to hold true for nightly!
<d1b2>
<rwhitby> Yeah, I need to add more vias
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
bgianf has quit [Quit: leaving]
bgianf has joined #glasgow
GNUmoon has quit [Ping timeout: 268 seconds]
smkz has quit [Quit: smkz]
smkz has joined #glasgow
<d1b2>
<rwhitby> An attempt at explaining jumper positions for various scenarios. Is it clear to anyone?
<d1b2>
<Attie> word of warning on the silk (circles and lines to indicate jumper placement)... diagramatically that works well, but i suspect yours may be too small to come out clearly
<d1b2>
<rwhitby> as long as it's a dot it's fine. it doesn't need to be a cirle
<d1b2>
<Attie> my concern was more about the line between - the circles are close and small, so it may just look like 6x dots
<d1b2>
<rwhitby> gotcha.
<d1b2>
<rwhitby> I want to put some sort of mnemonic on the board for that jumper set.
<d1b2>
<rwhitby> I agree about the size issue.
<d1b2>
<rwhitby> See anything else dodgy?
<d1b2>
<Attie> i've not dived in yet, but could have a skim over... i suspect electronic_eel will have done a good job
<d1b2>
<Attie> (been tight on time recently, sorry)
<d1b2>
<rwhitby> no need to apologise, I welcome whatever time people are generous to pay attention to it.
<d1b2>
<rwhitby> going to grunt chat working on the applet now
<d1b2>
<Attie> I'm not super comfortable with the jumpers / labelling - there seems to be a lot of flexibility, but it's split between soft and hard configuration
<d1b2>
<Attie> e.g: USBN is either connected to one side of the level shifter or the other... in one state, DIR needs to be driven interactively, in the other state, DIR needs to always be in the A->B state
<d1b2>
<Attie> i'm sure you've spoken about a more dynamic / software configurable supply... was this deemed too complex / abandoned for a reason?
<d1b2>
<rwhitby> DIR will always be driven by the applet.
<d1b2>
<rwhitby> If you want 1.2V, it's fixed. If you want 1.6V to 5.5V, then glasgow can control VIO.
<d1b2>
<Attie> my point is that DIR's behaviour will need to match the jumper's position, and thus the software / cli args need to match the physical configuration
<d1b2>
<Attie> also (for example) you could make it 1.2-5v, under the applets control, with no physical configuration required... and thus no conflict
<d1b2>
<rwhitby> but glasgow level shifters can't go down to 1.2V
<d1b2>
<Attie> e.g: if you connect USBN->USBN_3v3, and then the applet attempts to set DIR for A<-B, then you may have the remote and the level shifter driving the USBN_3v3 net
<d1b2>
<Attie> glasgow's cant, but there are shifters that can do this range
<d1b2>
<Attie> i'll pop into voice for a quick chat
egg|anbo|egg_ has joined #glasgow
egg|anbo|egg_ has quit [Remote host closed the connection]
sups has joined #glasgow
sups has quit [Client Quit]
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter has joined #glasgow
d_olex has joined #glasgow
<d1b2>
<TomKeddie> @rwhitby board is looking nice. I wonder if the jumper situation might best be handled with a block diagram on the underside showing their operation? Also wondering if the USB connectors are identical or if they need labelling to clarify their function?
bvernoux has joined #glasgow
egg|anbo|egg_ has joined #glasgow
roamingryan has quit [Quit: WeeChat 3.0.1]
egg|anbo|egg_ has quit [Remote host closed the connection]
jstein has joined #glasgow
GNUmoon has quit [Ping timeout: 268 seconds]
<electronic_eel>
rwhitby: updated your addon repo, coming along nicely
<electronic_eel>
I'm with attie that the jumper dots on silkscreen could come out unreadable or confusing
<electronic_eel>
how about a more elaborate version on the back side and just keep the pin designations on top?
<electronic_eel>
someone who has the basic wiring concept memorized just has to look at the designations, everybody who is unsure has to look on the back
<d1b2>
<alen> +1 for jumpers dots on silkscreen come out confused
<electronic_eel>
about the mismatch between software config and jumper positions attie mentioned: yes, that could be a problem. glasgow doesn't care, the shifters on your addon will probably survive too. but the 1v2 dut you have connected? that could be blown
<electronic_eel>
i can understand that you didn't want the full variable voltage logic with a dac on the addon and so on, makes it more complicated
<electronic_eel>
so one basic thing you can always do: add a series resistor of for example 100 Ohms between your 1v2-shifters and the jumpers. so they are only in series if the 1v2 shifters are used, not when glasgow is used directly
<electronic_eel>
additionally you could replace the jumpers by analog switches. that way you move both parts into your applet, no risk of the user confusing jumper and software setting
<electronic_eel>
here are 2 analog switches that you could use, both available at LCSC and JLCSMT:
<electronic_eel>
they are pin-compatible, so you could use either
<electronic_eel>
i would power them from the 5v rail, that way their voltage range goes up to 5v.
<electronic_eel>
you could then use the currently unused pins A5 and A6 to switch them
<electronic_eel>
this would mean you would always switch both sbu pins and both d+- pins, but i think wanting different voltage levels between sbu1 and sbu2 is extremely rare
<electronic_eel>
i would still add the aforementioned series, just to protect the dut in case you configured the applet wrong. also it doubles as series termination
StM has quit [Ping timeout: 260 seconds]
<electronic_eel>
*series resistor
StM has joined #glasgow
GNUmoon has joined #glasgow
<d1b2>
<rwhitby> Hmm, I agree with the series resistors.
<d1b2>
<rwhitby> I'm not sold on going away from the jumpers for 1.2v as that's my hardware means of protecting the expensive M1 mini or macbook.
<d1b2>
<rwhitby> An analog switch there means a software error can damage the M1.
<d1b2>
<rwhitby> I agree with silk on back for jumper instructions.
<d1b2>
<rwhitby> Usbc connectors do need labelling. Vbus is different for them.
<electronic_eel>
rwhitby: when do you sleep? always when i wrote some review, you reply within minutes ;)
<d1b2>
<rwhitby> 8am here, I had a great 8h sleep.
<electronic_eel>
i remember working with people in australia was a timezone hazard in the past. but could be more of a thing for regular working hours here
<d1b2>
<rwhitby> Depends on the time of year too, cause DST goes in opposite directions
<electronic_eel>
oh right
<electronic_eel>
back to dut protection: when you confuse software setting and jumpers, the shifters and the dut will drive against each other. that could be damaging for the dut, even with the series resistor in place
<d1b2>
<rwhitby> But when people give their time to give constructive comments on my stuff, I prioritise responding.
<electronic_eel>
thanks
<electronic_eel>
with your argument for the jumpers you prioritise the danger of wrong voltages over direction, correct?
<d1b2>
<rwhitby> If dut is connected to 1.2v, it can't be damaged by Sw error.
<d1b2>
<rwhitby> If connected to 3.3v, then Glasgow should protect it?
<electronic_eel>
sure? when the direction pin is set to output, but you want input, the shifter drives against the dut
<d1b2>
<rwhitby> True, but that is true for any time you connect a dut to Glasgow.
<electronic_eel>
here you have the increased hazard of conflicting jumper and software setting. usually you just have one place (=glasgow) to decide. that is easier to get right
<d1b2>
<rwhitby> Yep, I don't argue with that.
<electronic_eel>
but you are right, if you connect 3v3 output to your dut, it will be fried
<d1b2>
<rwhitby> But I don't see how the eventual result of a mistake is worse than normal Glasgow case, once the mistake is made.
<d1b2>
<rwhitby> Also, all jumpers out is the safe state. Analog switch loses that.
<electronic_eel>
you could use pull ups/downs to set the jumpers to the 1v2 shifters and the direction to input. so when you reset glasgow, everything is safe too
<electronic_eel>
so you just press reset and everything is safe
<electronic_eel>
the question boils down to what you trust more: the software doing the right thing or the user being able to set the correct jumpers
<d1b2>
<rwhitby> I'm going to need to write the pros and cons down. I'm not discounting changing, but need to make sure it's worth it and it meets the goal of protecting the dut.
<electronic_eel>
yes, that is a good idea
<electronic_eel>
i'm not really against the jumpers, the arguments should just be carefully weighted
<d1b2>
<rwhitby> I only trust the user enough to put them on 1.2v for macbook. Not to keep the Sw in sync.
<d1b2>
<rwhitby> Bit maybe that trust is misplaced.
<electronic_eel>
the software has more ways of cross-checking stuff. for example you could take the usb comms with the FUSB302 into account when deciding what to do
<electronic_eel>
does apple use some special custom sbu mode for communicating with the debug port of the M1?
<d1b2>
<rwhitby> You have to set it up with VDMs first.
<d1b2>
<rwhitby> That switches a mux in the M1
<electronic_eel>
so you have to ask the M1 over the cc lines to enable this special mode, correct?
<electronic_eel>
in that moment you would automatically force the analog switch on the addon into the 1v2 mode
<electronic_eel>
as long as the user doesn't completely break your applet with buggy patches, the M1 will be safe then
<electronic_eel>
no jumpers that could be set in the wrong way
<electronic_eel>
you should just write this part of the applet in a very clear and well commented way, so that it does not invite users to break this part of the applet when they want to change something
<electronic_eel>
but while you develop on this part of the applet and get the logic wrong, you have no easy hardware way to prevent the applet from doing bad stuff
<d1b2>
<rwhitby> Right, safety while testing applet too is important
<electronic_eel>
hmm, maybe 2 pin jumpers in series between the usb connectors and the analog switches? then you could completely disconnect all io on the addon and glasgow until you are sure the applet works
<electronic_eel>
later when everything works they would be permanently set, no room for error there
<electronic_eel>
but during development you could remove them and use a scope to verify the analog switches are correctly configured
umarcor has quit [Read error: Connection reset by peer]
jstein has quit [Quit: quit]
<d1b2>
<rwhitby> Looks like a 2 pin and an analog switch can fit in the same space as a 3 pin ....