<marcan>
so now it properly cuts out, but the regulator still doesn't turn off, even though it has plenty of input voltage
<marcan>
somehow EN is stuck at 0.5V or so, maybe that's not low enough
<marcan>
wonder where that is coming from
<marcan>
the datasheet says 0.5V max, so this is on the edge of problematic
<marcan>
whitequark: I'm going to lower the EN pin pulls to 10K. we want those to be responsive anyway.
<marcan>
I don't know where that 0.5V is coming from, but...
<whitequark>
ack
<marcan>
lol I had a massive PEBKAC, but it helped us find the supervisor problem...
<marcan>
the weird behavior with the slow brownout was because... I had neglected to solder the GND pin of the regulator...
<marcan>
unfortunately now we're back to dying instantly at 0.1Ω protection resistance
<marcan>
EN definitely doesn't fall fast enough though, so 10K down is still a good idea, let me see if that helps any
<whitequark>
oh
chocol4te has joined #glasgow
<marcan>
whitequark: so we still have the problem that we're crowbaring the 5V rail way too fast for anything to react
<marcan>
I wonder if what we need is just a bunch of capacitance there
<marcan>
we don't really have any bulk decoupling...
<marcan>
4u7 max is really pretty low
<marcan>
basically the situation now is that when the output is shorted, 5V goes to **zero** in microseconds, then recovers to 0.5V or something some 600µs later, but by then it's too late
<marcan>
this might be simply caused by e.g. USB cable inductance
<marcan>
let me just tack on an electrolytic across the 5V rail (after the current limit)
<marcan>
or a tantalum if I have one
<marcan>
ha, that worked.
<whitequark>
:D
<marcan>
yeah, this fixes everything, even on the A side that has no mods
<marcan>
basically our problem is that the 5V rail was getting crowbared too fast, before the downstream regulator could react
bgamari has quit [Ping timeout: 276 seconds]
bgamari has joined #glasgow
<marcan>
whitequark: yeah, the other part of the puzzle is the upstream USB VBUS source's own transient response; I get pretty different results on e.g. a powered hub vs my thinkpad
ender| has joined #glasgow
<marcan>
whitequark: so the other consideration here is that we don't *really* have clean brownout protection with the LM3880, because it does a controlled shutdown
<marcan>
without any capacitance, if we lose power, the FX2 is never reset; everything just falls uncontrolled
<marcan>
with 220uF and no load, the 5V rail drops slowly enough that 16ms after we hit 4.1V we're still good to power the FX2, so reset is asserted semi cleanly before the 3V3 rail dies
<marcan>
but if we had any load of course that wouldn't happen either
<marcan>
but ideally if we brownout we'd be killing the FX2 asap, I think
<marcan>
OTOH, this is actually good in this case, because on load transients the timeout never expires and the FX2 never resets
<marcan>
if we were browning out immediately, a transient on the A port with no series resistance would cause an FX2 reset
<marcan>
I think in the end basically I'm going to implement all of these mitigations anyway
<marcan>
the only one I haven't done yet is the higher-spec current limit on VBUS, but now I think that's not the problem at all
<marcan>
since as soon as we have capacitance on 5V, the downstream regulator can trigger its current limit first and we don't wind up in a broken state
<marcan>
so maybe we can stick with the 500mA limit
<marcan>
esden: do you have any opinions on bulk capacitance?
<marcan>
e.g. >100µF
<electronic_eel>
marcan: sounds like a good analysis of the problem to me
<electronic_eel>
as I said earlier I was using this usb protector with resistor controllable limit
<electronic_eel>
I used it with a 150µF polymer cap, as that was recommended in the datasheet
<electronic_eel>
that worked fine on the first try, so I think adding some electrolytic or polymer is a good solution
<marcan>
yeah
<marcan>
(wonder if I can fit that anywhere, lol)
futarisIRCcloud has joined #glasgow
<electronic_eel>
only problem when you really want to adhere to the usb spec: they don't allow to put a bigger capacitance directly on the input
<electronic_eel>
they say it should be switched on after enumerating or limited with a resistor
<electronic_eel>
I haven't experienced problems with neglecting this, but I only violated it on hobby projects
<marcan>
well we do have the current limit in front
<marcan>
which *should* avoid the transient
<marcan>
I can try measuring that
_whitenotifier-3 has joined #glasgow
<_whitenotifier-3>
[Glasgow] marcan commented on issue #135: Regulator behavior after short circuit - https://git.io/fjGpF
<whitequark>
marcan: sgtm
<marcan>
whitequark: ack on what I said on the issue?
<marcan>
do we want to keep the 500mA overall current limit or up to 1.5A?
<marcan>
(or do you want me to at least test it?)
<marcan>
(I have the parts)
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±3] https://git.io/fjGph
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan 2edcf4a - revC1: fix LM3880MF EN divider for 4.1V brownout
<whitequark>
marcan: I'd say test it, we're quite marginal on the 500 mA limit especially if powering something else
<whitequark>
marcan: I made a "Waiting for Godot" joke on twitter earlier and got called out savagely.
<whitequark>
with "Waiting for Glasgow" as a reply.
<marcan>
lol
<marcan>
so, er, the existing current limit doesn't seem to be working properly?
<marcan>
like, upstream VBUS is getting murdered
<marcan>
have I killed mine with all these experiments or...?
<whitequark>
marcan: what
<whitequark>
what do you mean?
<marcan>
I mean if I short out the internal 5V rail, VBUS dies and e.g. if it's connected to my 16-port USB hub everything else connected to it dies
<ender|>
where'd you get a 16-port hub (and is it an actual 16-port hub, or just 5 4-port hubs glued together)?
<marcan>
the latter
<marcan>
and, um, amazon japan? :p
<whitequark>
marcan: ohh
<whitequark>
interesting
<ender|>
USB2 or 3? and if it's 2, does it leak current upstream?
<marcan>
okaay this thing is letting me pull 3A steady state from USB
<marcan>
either it's dead or what the fuck
<whitequark>
whaaat
<marcan>
ender|: 2 and no, because it's powered only
<marcan>
requires external power, no upstream path
<marcan>
I like it, it provides lots of oomph (as evidenced by how I just pulled 3A out of it and it didn't bat an eye)
<marcan>
3.4A lol
<marcan>
whitequark: I'm going to replace it with another 500mA one for now, assuming I somehow killed it with all these tests
<ender|>
so far i only found one USB2 hub that doesn't leak upstream (and makes the chipset fan on my motherboard spin while the computer is off)
<marcan>
whitequark: multimeter shows vbus shorted to internal 5V, I think it croaked
<whitequark>
innnteresting
<whitequark>
marcan: cable inductance killing it?
<marcan>
no idea, but yeah, 0.1 ohms across that fet lol
<marcan>
whitequark: it seemed to die recently, possibly when I soldered a wire to the VBUS pin, so maybe it was an ESD issue
<whitequark>
isn't it supposed to provide esd protection?
<marcan>
yeah well I dunno :p
<marcan>
whitequark: good news: 10µF ceramic is enough to solve the crash problem. it does brown out 3V3 down to 2.2V or so, but it recovers without a reset.
<marcan>
lower ESR helps I guess.
<marcan>
well, 10µF in parallel with the existing 4.7µF
<electronic_eel>
what size ceramic? 0603? 0805?
<marcan>
1206, heh
<electronic_eel>
that matters. 0805 10µ will already be a lot less at 5v
<marcan>
I think I can fit a 1206 in there somewhere
<electronic_eel>
maybe better to add some more 4.7µF in parallel than one big 10
<electronic_eel>
won't need another reel then
<marcan>
true
<marcan>
though I still think we'd want more capacitance than that
<whitequark>
four 4.7u?
<marcan>
I want to know what esden thinks about using a tantalum or whatever
<marcan>
like four 4u7 on top of the two we have in revC1?
<marcan>
(up from one because we split the regulators)
<electronic_eel>
I'd be careful with tantalum
<marcan>
(but I want to keep that as safety margin)
<marcan>
let me just try putting 4 in parallel here and see what happens
<marcan>
4x4u7 is not enough
<marcan>
probably because it's a much smaller package, lower capacitance at 5V
<marcan>
whitequark: this is clearly not going to impact this issue at all, but want me to just throw on the 1.5A limit switch and do $something to it?
<marcan>
the crowbar transient has nothing to do with it (vbus == 5V) so it's not going to change this situation at all
<marcan>
it just matters for our current limit
carl0s has joined #glasgow
<marcan>
(and for recovery after a crowbar hard enough to take out the system, but the 0.68Ω + cap avoid that situation)
<marcan>
looks like the current limit is about 0.8A
<marcan>
(on the 500mA version)
<marcan>
whitequark: the other thing I can do, if you want, is dead-bug wire up the new regulators in place of the MIC just to validate them
<marcan>
it won't be fun but I *can* do it :p
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjZfZ
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan 3068ca1 - revC1: add additional current-carrying vias to USB GND
<marcan>
that's voltage, not current, but doing the math with the known capacitance, it's 0.75A or so, which is what we expect based on the current limit
<marcan>
so I think that's reasonable for a USB device, and also a good reason not to use the 1.5A current limit switch (which might be too much inrush load for some hosts, even when the user isn't using that much current)
<marcan>
CH1 is upstream VBUS, CH2 is the 5V rail on the glasgow
<marcan>
(ignore the vmax thing, my scope is being stupid)
<electronic_eel>
marcan: is that with your 220µF electrolytic or did you use something else?
cr1901_modern1 has joined #glasgow
cr1901_modern has quit [Ping timeout: 250 seconds]
<marcan>
electronic_eel: 100µF
<marcan>
(which is what we specced for the final one)
<electronic_eel>
ah, ok
<electronic_eel>
what is going on for the first millisecond or so, where vbus is there but the 5v rail not yet rising?
<marcan>
presumably the current limit switch has a turn-on delay
<electronic_eel>
ah, probably against contact bounce
<electronic_eel>
nice feature, haven't seen that before
<marcan>
datasheet says 1.6ms typ
<electronic_eel>
I think the inrush current will be ok for the big majority of usb hosts/hubs this way
<electronic_eel>
will probably brownout a passive hub, but Glasgow won't work that way anyway
<electronic_eel>
i think this part of the usb spec was written with passive hubs in mind
<marcan>
lol, actually, the datasheet says
<marcan>
When implementing
<marcan>
USB standard applications, a 120 µF minimum output capacitance is required. Typically a 150-µF electrolytic
<marcan>
capacitor is used, which is sufficient to control voltage undershoots.
<marcan>
should've read it a long time ago :p
<marcan>
I'm going to see if we can bump up the value a bit in the same footprint
<electronic_eel>
that is regular electrolytic, not polymer
<electronic_eel>
compare the esr!
<marcan>
yeah
<electronic_eel>
360m against 27
<electronic_eel>
also lifetime, 2000h against 15000
<marcan>
APXF6R3ARA151ME40G has more stock in mouser
<marcan>
higher ESR but lower profile
<electronic_eel>
APXF100ARA121ME61G
<electronic_eel>
120µF, 10V, 22mOhm
<marcan>
I feel better about 150
<marcan>
APXF6R3ARA151ME40G is 150µF, 20mOhm
<marcan>
6.3V though
<marcan>
I don't think there are any 150µF ones in 10V in that form factor
<electronic_eel>
no, I think that is about the limit what you can get out of that size
<electronic_eel>
I don't have experience with 6.3v caps at 5v
<electronic_eel>
I always used 10V or 16V caps for 5v application
<marcan>
6.3 is 5V at 80% derating
<marcan>
which is "supposed" to be okay
<electronic_eel>
yes, "supposed"
<electronic_eel>
but sometimes appliances are "supposed" to fail right after the end of warranty...
<electronic_eel>
you tested with a low-spec 100µF and it was ok, right?
<marcan>
eh, these aren't CapXon caps :p
<electronic_eel>
ok, say sorry to your cap
<marcan>
yeah, I tested with some shitty-ass 100µF, but it *was* dropping below 3V3 which, while survivable, was not ideal
<electronic_eel>
I didn't mean to offend it
<marcan>
no I mean, the ones we're speccing
<marcan>
the one I tried, yeah, no idea wtf it is
<marcan>
some random ass thing
<marcan>
probably shit :p
<marcan>
also old
<marcan>
(but I did measure it first, it is 100)
<marcan>
label says Punsumi
<marcan>
some indian brand?
<electronic_eel>
you have an lcr meter at hand?
<marcan>
nope
<electronic_eel>
so, better voltage derating or more capacitance?
<marcan>
I think I want to go for the 150µF 6.3V one for now; at the usage a Glasgow is going to get and with proper name brand caps I doubt it's going to go bad caps on anyone
<electronic_eel>
yeah, ok, 150µF
<marcan>
so APXF6R3ARA151ME40G
<electronic_eel>
yes
<electronic_eel>
marcan: have you read my chat with whitequark about the voltage protection addon board?
<marcan>
skimmed it
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±2] https://git.io/fjZLI
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan 7303692 - revC1: bump 5V cap to 150µF
<marcan>
looks like a neat circuit
<electronic_eel>
yeah
cr1901_modern1 has quit [Quit: Leaving.]
<electronic_eel>
I thought a bit more about it
cr1901_modern has joined #glasgow
<electronic_eel>
I think I can't get it to work without a separate reference for vio
<_whitenotifier-3>
[Glasgow] marcan commented on issue #135: Regulator behavior after short circuit - https://git.io/fjZLL
<electronic_eel>
do you mind adding testpoints for the dac outputs to the bottom side of Glasgow?
<electronic_eel>
I think that is the best way to tap into, put an opamp behind and create my reference point from that
<electronic_eel>
can't be an officially supported addon this way of course
<electronic_eel>
how is the reset of the ice40 designed to work?
<marcan>
if the fx2 gets reset it needs to be reloaded, and then the ice40 should end up reset too
<marcan>
I didn't test that but I don't see why it wouldn't work
<marcan>
the FX2 drives the ice40 reset
<electronic_eel>
is this reset done explicitly by code in the fx2
<marcan>
yes
<electronic_eel>
or is it just the 100k pulldown?
<esden>
marcan: I am pretty busy this week. I will still try to do a pass on the board. I do not follow the nuance of the changes. But as an utter "hot take" it is becoming pretty complicated. So many "protection" devices on there. Would cutting them out not make it much simpler and still cover 99% of the uses of the device? How many placements would we save with that? How much in BOM cost would we save with that?
<marcan>
electronic_eel: it's pushpull
<marcan>
the pulldown is just for when the FX2 code hasn't initialized yet
<electronic_eel>
and don't like burning tantalums ;)
<marcan>
esden: ESD protection is kiind of important considering the shifters do not have high side diodes, and it's just like $1 extra BOM cost and two chips? plus one discrete for SYNC
<electronic_eel>
esden: the board will be connected to some unknown DUTs, hot insert is like the default use case and so on
<marcan>
plus two more of the same diode for the AUX pins, but those can be DNP if you really want to, I think, since we don't guarantee that port much
<esden>
I need to read deeper into the whole justification of having bulk capacitance in such huge amount on the board. I rather not have it, not have a inrush limit chip, and just deal with a user overloading the board and browning it out some times, saves bom cost and complexity. As I said, it is really becoming an _expensive_ device.
<electronic_eel>
I think adding some protection makes sense there
<esden>
not sure the cost is justified
<marcan>
esden: the bulk capacitance is necessary, it fixes a real problem
<marcan>
and also matches the spec of the current limit switch
<esden>
ok, will read into it in more detail then
<marcan>
the switch was already there from day one, that isn't new
<esden>
ok I did not pay attention to it. I would just keep the V_USB connectet capacitance under 10uF and not have the inrush current limiter. But ok.
<esden>
I like things simple and maybe not "perfect" :)
<marcan>
the only things we've changed BOM-wise since you last saw it are added the ESD protection (two partnos, 5 devices total), replaced the one combi regulator with two discretes because it's not available any more, and mucked around with a bunch of resistors (I actually eliminated one value!)
<marcan>
and added the extra vio leds (existing partno)
<marcan>
and the big cap
<marcan>
the vusb protection was there in revB even :-)
<tnt>
do you have a rought estimate of the bom cost alone ?
<tnt>
-t
<esden>
I generally think it should not be necessary for a small tool. The glasgow has the highest count of IC of any device I ever had the pleasure to consider putting together.
<marcan>
but really, as I've experienced, transient response of vusb without bulk capacitance is garbage even with "good" supplies, so that bulk capacitance is a really good idea (and lets the device properly survive shorts)
<marcan>
esden: so it's a challenge then :-)
<esden>
it is something that I would like to revisit some time and really think why, and "is it reeeeally necessary to cover 99%" how many tail 9s do we really want to cover. :)
<electronic_eel>
the ATECC crypto ic is something that isn't really necessary
<marcan>
I mean if you really want to you can DNP the ESD protection, but does it really save us that much? is it worth the $2 lower BOM cost to risk killing IOs if you touch them wrong?
<esden>
marcan: I do not disagree. To make things "pretty" and "done right". :)
<esden>
the balance is always, what is the cost tradeoff worth?
<marcan>
I mean the whole point of this thing is that it is supposed to be robust, because it will be abused
<marcan>
electronic_eel: take that up with whitequark :p but that chip is optional by design.
<marcan>
(and not even used yet)
<esden>
I do not argue against the ESD protection parts. Especially if the ice40 is so fragile. But is it?
<marcan>
mostly the ESD protection is for the level shifters
<tnt>
IOs are not connected to the ice40
<marcan>
they aren't that fragile, but they do not have high-side diodes, and that is scary
<marcan>
tnt: well AUX is
<marcan>
but yeah
<esden>
My take was on the STM32 devices. They are robust enough, and do the users want to pay for that?
<esden>
but it is more of a philosophy question
<tnt>
marcan: why is the lack of high side diode scary ?
<marcan>
it's a design decision; the idea is that your glasgow shouldn't randomly break, it's a tool you should be able to freely use and even abuse
<electronic_eel>
I have fried enough stm32 io pins on devboards...
cr1901_modern1 has joined #glasgow
<marcan>
(which is why we did things like test the short circuit performance of the shifters for 20h...)
<marcan>
tnt: because it means there is nothing to clamp positive voltage spikes
<marcan>
and the datasheet ESD spec for the shifters is... mediocre
<tnt>
marcan: oh I thought they'd just have diodes back to back to gnd.
<marcan>
no, that would clamp too much
<marcan>
it's -0.7V to GND, but nothing to Vcc
<esden>
marcan: that makes definitely sense for 1000k or more expensive devices. But is it really true for a $150 device? $2 BOM results in $8 added retail cost.
<marcan>
the ESD protection we threw in is specced for 5V through to GND, which protects against positive spikes (and -0.7V negative spikes)
cr1901_modern has quit [Ping timeout: 255 seconds]
<tnt>
esden: I think 150$ is optimistic at this point :p
<esden>
tnt: totally
<esden>
it is more like a $200 device by now.
<marcan>
anyway, I'll let whitequark fight the rest of this fight
<marcan>
I'm going to sleep :p
<esden>
no totally, I agree, I do not want to desway, just adding a bit of perspective. :)
<esden>
that is why I said "hot take" :D
<esden>
marcan: have a good night and sleep well :)
<electronic_eel>
marcan: good night
<marcan>
and hey, if bunnie can sell a whole SoC board with RAM and a quadcore CPU and some Xilinx FPGA and a bunch of other crap for $550, surely we can put together an FX2 and an iCE40 and some level shifters for $150 :D
<marcan>
esden: either way I'm looking forward to your estimate on BOM and retail costs
<esden>
marcan: I do think the glasgow capability is worth $200 or even more. Some people may still choose to compare it to buspirate or a FTDI breakout board. :)
<marcan>
those people can die in a fire :-)
<esden>
marcan: will try to get it for you as soon as I can.
<esden>
marcan: hahaha, yeah :)
<electronic_eel>
their ftdi breakouts will die in fire cause they don't have esd protection ;)
<esden>
electronic_eel: but you can buy a new one for $10 so it is not a big deal. :)
<tnt>
So far in all my years of playing with shit, I burned 1 IO ...
<electronic_eel>
esden: not on a sunday morning when you want to do some developing
<esden>
tnt: yeah you are the first person that I know that did that to be honest.
<esden>
electronic_eel: that is why you have a bunch flying around on your desk. :)
<electronic_eel>
like twenty or so? then I'd prefer one proper tool
<esden>
I definitely have more ftdi crap flying around than I would want to admit.
<marcan>
I've blown IOs before, also killed an LPC port on a motherboard due to floating earth and leakage through a PSU... ESD protection would've saved that
<tnt>
esden: Oh, I wasn't talking about the icebreaker. For that I reflowed the whole chip this morning and crossing my fingers this seems to have fixed it. Probably had a bad VCC or GND connection somewhere.
<marcan>
though considering the amount of shit I've done and my sheer laziness about ever wearing an ESD bracelet, I've had a pretty good run
<esden>
marcan: that is a very good point. Do not use shitty tools that can destroy the only prototype of a thing.
<electronic_eel>
I've blown some stm32 ios by having the stm32 powered down but connecting some powered uarts
<marcan>
it wasn't really shitty tools, just lack of earth grounding (because japan) and the standard Y cap leakage through a PSU
<esden>
or the only example of a thing... "mhh shit now I blew the only working example of the apollo computer" FUUUUU!
<marcan>
but then again I'm also the kind of guy that bought a humidifier the moment I realized things were dry enough in here a few months ago for sparks to start happening
<marcan>
anyway, nn!
<esden>
electronic_eel: I did burn STM32 IOs with gnd on a pin and 3v3 on GND reference. That is why the bmp got level shifters. :) That is why at the end whitequark and marcan most likely made the right design decisions on glasgow. I am coming totally underinformed and from the left field here. thus "hot take" :D
<esden>
marcan: nn :D
<electronic_eel>
esden: does the bmp still have these auto-direction-detection shifters?
<esden>
haha! No, I replaced them a very very long time ago. I only made about 50 of those. That was a big mistake.
<electronic_eel>
very good decision. Tried them once and had just problems with them
<esden>
yeah they are horrible. Only usable if you have 100% control over both sides of the communication and can assure it will always work.
<esden>
I keep seeing them in tools people make and sell. And it causes me to cringe every time.
<apo>
<3 my bmp
<esden>
apo: Great to hear that! :D
<esden>
I can't wait to get my glasgow! ;)
<esden>
(ohh right I am the one who has to make it ... damn)
<esden>
:D
<apo>
esden: make one for me as well while you're at it ;3
<esden>
haha! I will be making a few prototypes for validation, and then I will start making proper batches for everyone who wants to buy one. Don't worry. :)
<apo>
that's a better response than I got from marcan
<esden>
:D
* whitequark
wakes up
<whitequark>
$150 retail with our BOM cost is actually pretty reasonable
<whitequark>
esden: the IC count really shot up when we stopped using the autosensing level shifters.
<esden>
Yeah that totally makes sense. :)
<whitequark>
heaven knows i did not *like* that
<whitequark>
and capacitor count
<whitequark>
as for comparison to bus pirate... can buspirate do *anything* at 200 MHz much less capture or output on all 16 pins?
<esden>
I know. It is just me looking at the BOM like a goat at a painted door. (sorry that is a polish saying that fits here)
<whitequark>
or i guess more concretely
<whitequark>
let's say you have a 8 GByte NAND flash
<whitequark>
and you want to read it in less time than the heat death of the universe
<whitequark>
good luck with that
<whitequark>
it would be interesting to see what we can cut, but i'm thinking not much
<esden>
buspirate tends to crash every few minutes doing the most mundane thing... I personally do not want to compare glasgow to it... but this is how people tend to describe glasgow to someone who does not know anything about it. I heard it several times this weekend. :)
<whitequark>
esden: I am going to have to write a lot of words on that topic, wouldn't I
<whitequark>
but that's okay, that's what we have to do
<esden>
I bet there is a better one sentence description. Better than: "it is a much more sophisticated faster and better buspirate with level shifting and more"
<whitequark>
I am going to bump down the Bus Pirate comparison way deeper than "first line of README"