<azonenberg>
So i'm probably going to be buying sonnet gold some time in january
<azonenberg>
at this point i should finally be able to do full board simulations of my probes
<azonenberg>
rather than just bits and pieces
<azonenberg>
david.lenfesty: also if you havent gone through my signoff review checklist on the board, that would probably be a good idea
<d1b2>
<david.lenfesty> ah yep, thanks for the reminder. Not quite at that stage but close.
<azonenberg>
Once you're done with the design, what's the plan on assembly/firmware? were you going to order one and play with it yourself?
<azonenberg>
and if TiltMeSenpai is doing the probe, how are you going to handle the interop? are you each going to build one of each? or one build two of each then mail back and forth? or what
<d1b2>
<david.lenfesty> I was probably going to order one of both for myself once the probe was done.
<d1b2>
<david.lenfesty> Probe fw should be pretty simple so I'm fine with waiting until @TiltMeSenpai is done or if they don't want to build their own board acting as a debugger for a work session at some point in the future.
<d1b2>
<david.lenfesty> The gateware can wait a while because I plan on mocking everything up in CocoTB before I do any serious hardware debugging
<d1b2>
<david.lenfesty> but I also don't want to test it on any hardware other than the probe at first because the only USB C stuff I have I would like to not kill
<d1b2>
<TiltMeSenpai> I think actual functional testing might require the probe
<d1b2>
<TiltMeSenpai> I can't do much other than send a "yep that's a debug peripheral" signal to the MCU without both parts
<d1b2>
<TiltMeSenpai> hmmm
<d1b2>
<david.lenfesty> tbf that's all that's required of the probe
<d1b2>
<david.lenfesty> (for proof of concept)
<d1b2>
<TiltMeSenpai> well, not even "yep that's the right debug peripheral"
<d1b2>
<david.lenfesty> well, for PoC all the probe needs to do on boot (i.e. when it gets 5V) is huck a couple bytes of UART over SBU1
<d1b2>
<david.lenfesty> I guess and be able to accept some messages
<d1b2>
<david.lenfesty> but you can test that without the host side too, as long as you have some test points
<d1b2>
<TiltMeSenpai> yeah I was just gonna chuck down one of these https://www.st.com/en/interfaces-and-transceivers/stusb1700.html and like either a atsamd11 or stm32 (it literally doesn't matter bc we just need uart, i2c and like 1 or 2 interrupt lines)
<d1b2>
<david.lenfesty> do we even need the USB C controller on the probe side?
<d1b2>
<TiltMeSenpai> nah, that's for the host side
<d1b2>
<TiltMeSenpai> the host side is relatively important because you could plug a charger into it
<d1b2>
<david.lenfesty> yeah I've got that bit designed already
<d1b2>
<TiltMeSenpai> oh you did the host?
<d1b2>
<david.lenfesty> were you not doing the probe?
<d1b2>
<TiltMeSenpai> I thought I was doing a host board
<d1b2>
<TiltMeSenpai> lol
<d1b2>
<david.lenfesty> huh, looks like I was mistaken
<d1b2>
<david.lenfesty> looking back at the original convo
<d1b2>
<TiltMeSenpai> I mean I can do a probe board, that's even simpler I think
<d1b2>
<david.lenfesty> you were talking about the scope side
<d1b2>
<david.lenfesty> which my brain messed into probe I think
<d1b2>
<TiltMeSenpai> I just need to think a bit about input protection, it would theoretically be possible to plug a probe into a misbehaving charger that just dumps 20v into it
<d1b2>
<david.lenfesty> hope I didn't step on your toes there or anything
<d1b2>
<TiltMeSenpai> I hadn't done anything other than select the PD chip, I figured it would be a decent project to relax to, but never really got around to it. It's fine, I didn't waste work
<d1b2>
<TiltMeSenpai> hmm, "trip at ~6v, tolerate up to 25v, no external fet required, small package" results in a pretty tiny selection of overvoltage ic's
<Bird|otherbox>
TiltMeSenpai: yeah, I think that's a fair concern re: someone plugging a probe into a Cheesium charger by accident
<d1b2>
<TiltMeSenpai> I guess that's a long-ish list of requirements, but that seems like a common list
<Bird|otherbox>
yeah, I think that going with something that uses an external FET might free things up a bit there
<d1b2>
<TiltMeSenpai> I think if we're not going with a dedicated pd IC and FET's, the scope side might need to be careful of that
<d1b2>
<TiltMeSenpai> the evil chargers
<d1b2>
<david.lenfesty> uuuuhhh also: > A USB Type-C Cable does not pass both CC wires so a receptacle to receptacle Debug Accessory Mode connection cannot be detected
<d1b2>
<TiltMeSenpai> oh what
<d1b2>
<david.lenfesty> from the type C spec
<d1b2>
<david.lenfesty> Appendix B.2.3.1
<d1b2>
<TiltMeSenpai> eww
<d1b2>
<david.lenfesty> page 316
<d1b2>
<TiltMeSenpai> how does pd negotiation work then
<d1b2>
<TiltMeSenpai> I thought you need both CC wires
<d1b2>
<TiltMeSenpai> oh there's only 1 cc line in the cable. Rip
<Bird|otherbox>
the other CC line is actually Vconn, used to power active cables
<d1b2>
<TiltMeSenpai> so in a passive cable, should both CC lines be expected to be connected?
<d1b2>
<david.lenfesty> I don't think so
<d1b2>
<TiltMeSenpai> after initial negotiation, it looks like "CC2" from the host's perspective goes to VCC
<d1b2>
<david.lenfesty> it's just ignored or passed through afaik
<d1b2>
<david.lenfesty> well could be CC1 or CC2
<d1b2>
<david.lenfesty> depending on which one is actually CC
<d1b2>
<TiltMeSenpai> is our debug peripheral idea dead then
<d1b2>
<david.lenfesty> methinks the USB IF explicitly wanted to disallow our plan
<d1b2>
<david.lenfesty> unless we used a captive cable
<d1b2>
<david.lenfesty> which is one custom, non type-C end
<d1b2>
<david.lenfesty> yeah I don't think we can use debug access mode
<d1b2>
<david.lenfesty> *accessory
<d1b2>
<TiltMeSenpai> what's the official usage of the SBU pins in USB 2.0 mode
CyberDre has joined #scopehal
<d1b2>
<david.lenfesty> not sure
<d1b2>
<TiltMeSenpai> aka will anything break if we try to talk 3.3v UART to a not-active probe and skip the debug accessory detection step
CyberDre has quit [Client Quit]
<d1b2>
<TiltMeSenpai> yes, this is bad but so is like all of USB so
CyberDre has joined #scopehal
<d1b2>
<david.lenfesty> honestly I was surprised at how good type C was in my previous understanding
<d1b2>
<david.lenfesty> less surprised now
<d1b2>
<TiltMeSenpai> alternate mode negotiation should happen on the CC line(s)
<d1b2>
<TiltMeSenpai> so SBU should be unused until we negotiate it to be used for something, the only question is if there's anything out there that would freak out about seeing unexpected signals on the SBU pins
<Bird|otherbox>
yeah, the alternate mode negotiation mechanism runs over the USB-PD protocol
<d1b2>
<david.lenfesty> If we are using PD to communicate we don't need SBU at all and should just use PD in the first place
<Bird|otherbox>
yeah, that too
<d1b2>
<david.lenfesty> bird|otherbox: weren't you suggesting we just use PD?
<d1b2>
<TiltMeSenpai> do you want to try behaving like a fully compliant PD host?
<d1b2>
<david.lenfesty> you knew all along you little rascal
<d1b2>
<TiltMeSenpai> I was suggesting both ends go passive on PD, and abuse the SBU pins without prior permission
<d1b2>
<david.lenfesty> I would like to investigate SBU before implementing PD
<Bird|otherbox>
yeah, that was my initial thought when I started looking at it -- using the PD alternate mode negotiation system, perhaps supplemented by vendor-defined PD messages
<d1b2>
<TiltMeSenpai> my intuition is this should work even though it's not compliant by any definition but
<d1b2>
<david.lenfesty> If we did direct attach or captive cables we could get away with using debug mode and operate entirely over SBU and be spec-compliant
<d1b2>
<david.lenfesty> but alas, we cannot
<d1b2>
<david.lenfesty> I'm gonna do some more digging. Ask in #usb-hacking as well if anyone knows more about SBU, it seems to be fairly ill-defined
<d1b2>
<TiltMeSenpai> I would personally like to avoid multiple PD phy's and implementing a full PD compliant interface if possible, and if nobody's looking at the SBU pins, it might be acceptable to be wildly out of spec there
<Bird|otherbox>
TiltMeSenpai: apparently one application for the SBU pins is to carry audio signals?
<d1b2>
<TiltMeSenpai> but that also requires a CC resistor setup I think
<Bird|otherbox>
yeah, that is true
<d1b2>
<TiltMeSenpai> what are "normal" audio voltage ranges anyways
<d1b2>
<david.lenfesty> glances at electret speakers
<d1b2>
<david.lenfesty> *electrostatic speakers
<d1b2>
<TiltMeSenpai> by "normal" I mean something that you find in your home that has a coil
<d1b2>
<TiltMeSenpai> I wouldn't be surprised if like stadium speakers also use silly voltage ranges
<Bird|otherbox>
it'd be linelevel audio, so less than a few volts
<Bird|otherbox>
the other use I'm finding for SBU is for the AUX channel in the DP alt mode
<d1b2>
<TiltMeSenpai> huh, I was going to say worst case, we're scared that 3.3v signals on SBU will hurt something, and we use 1.8v logic
<d1b2>
<TiltMeSenpai> but if the worst designers are planning for is line level audio finding its way to SBU, even 1.8v might be a bit much?
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #scopehal
<d1b2>
<david.lenfesty> so we are supposed to put SBUx pins into "safe" levels when transitioning into/out of alternate modes
<d1b2>
<david.lenfesty> which is 1.5V common mode
<d1b2>
<david.lenfesty> *0-1.5V common mode
<d1b2>
<david.lenfesty> checking if it needs to stay there during normal operation
<d1b2>
<TiltMeSenpai> so 1.8v logic should be "safe"
<Bird|otherbox>
close to it
<Bird|otherbox>
btw: DP AUX signaling is ~1V P-P Manchester encoded data
<Bird|otherbox>
half-duplex bidirectional too
<d1b2>
<TiltMeSenpai> hmmm but if we want the active probe to have usb dfu, we need 3.3v (then again, who would even want that lol)
<d1b2>
<david.lenfesty> uuuuuuhhh SBU is used as 3.3V 8n1 at some baud rate
<d1b2>
<david.lenfesty> uses it's own protocol
<d1b2>
<TiltMeSenpai> during USB operations?
<d1b2>
<david.lenfesty> I think so
<d1b2>
<TiltMeSenpai> ideally I think both the host and probe should show up as legacy USB-C devices until you handshake over SBU or whatever
<d1b2>
<david.lenfesty> ah I'm dumb, its 1mbps
<d1b2>
<TiltMeSenpai> so if we only have pull resistors on both sides, is there any expectation that SBU functions by USB-C definitions?
<d1b2>
<david.lenfesty> let me check
<d1b2>
<david.lenfesty> looks like it needs to negotiate over PD to enter USB4 mode
<d1b2>
<david.lenfesty> which is when we would expect that 1mbps signalling to start happening
<d1b2>
<TiltMeSenpai> usb 4...
<d1b2>
<TiltMeSenpai> lol
<d1b2>
<david.lenfesty> so looks like in-spec, the only uses for SBU are USB4, Alternate modes, and audio adapter accessory
<d1b2>
<TiltMeSenpai> well I think it's decidedly out of spec but in a manner that nobody's paying attention to
<d1b2>
<david.lenfesty> I'm still a little scared about it
<d1b2>
<david.lenfesty> but there's plenty of time to do more research before we get boards out
<d1b2>
<david.lenfesty> although it doesn't really change much about the design either though
<d1b2>
<TiltMeSenpai> yeah and the probe is like <$5
<d1b2>
<TiltMeSenpai> I think shipping is gonna be about triple my material costs lol
<d1b2>
<david.lenfesty> yeah the only difference is you only need one pullup resistor
<d1b2>
<david.lenfesty> > The SBUpins on a portshall either be open circuitor have a weak pull-down to ground no stronger thanzSBUTermination.
<d1b2>
<david.lenfesty> That's enough for me. If it's spec compliant it should be capable of taking what we give it
<d1b2>
<TiltMeSenpai> who do we care more about having some semblance of compliance
<d1b2>
<TiltMeSenpai> one side could probably get away with like 10k resistors to ground, no?
<d1b2>
<david.lenfesty> I don't think we need to adhere to the spec
<d1b2>
<david.lenfesty> just saying if we plug anything else in that's spec compliant it should be safe for them
<d1b2>
<TiltMeSenpai> ah, ok, good enough for me lol
<d1b2>
<david.lenfesty> also if we go for an stm32f042 on the probe side we can do firmware updates over USB
<d1b2>
<david.lenfesty> just by closing a jumper or something
<d1b2>
<TiltMeSenpai> there's also bootloaders for the atsamd11 that do the same thing
<d1b2>
<TiltMeSenpai> and I think the atsamd11 is like the cheapest usb capable mcu around (sources needed)
<d1b2>
<david.lenfesty> well azonenberg was talking about using STM32 parts because that's what is used elsewhere
<d1b2>
<TiltMeSenpai> yeah
<d1b2>
<david.lenfesty> to keep the toolchains the same
<d1b2>
<david.lenfesty> so now I'm just debating direct-attaching SBU to the FPGA
futarisIRCcloud has joined #scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
CyberDre has quit [Quit: Konversation terminated!]
<azonenberg>
TiltMeSenpai: My plan is Spartan-7 FPGA host side, preferably fitting up to four host interfaces into an xc7s6
<azonenberg>
and stm32 probe side
<azonenberg>
And yes. USB logo compliance is absolutely not required
<azonenberg>
since we're not using actual usb, or claiming to
<azonenberg>
The goal is to ensure that usb-c cables will work, and that plugging in an actual usb-c device will not damage either end
<azonenberg>
I am still open to switching to a different connector if somebody has a better idea
<azonenberg>
usb-c was just something readily available and low cost
juli966 has joined #scopehal
m4ssi has joined #scopehal
<azonenberg>
New SFF8087 cable (half the length of the last one) arrived
<azonenberg>
gonna do some testing with it
<d1b2>
<TiltMeSenpai> yeah, in that case I think I'm personally ok with just throwing 3.3v UART over the SBU pins without asking first. Someone did mention that they had a USB C cable without the SS pins connected though, so maybe the probe should have some error state pins to alert if the +/-7v doesn't come up when it should?
<agg>
lots of usb c-c cables are usb 2.0 only, so no SS
<agg>
I'm not sure I even own any SS-cable usb-c cables
<agg>
but have a whole lot of c-c 2.0 for charging things etc
<agg>
wonder if you'd be better doing uart over d+/d- :p that way the cable even does the swapover for you
<agg>
ah, but without SS you don't get power conductors, so nevermind
<d1b2>
<TiltMeSenpai> I also think that we should leave the D+/D- pins open for actual usb 2.0 use. It seems like a simple way to sneak in a debug connector with minimal extra effort
<d1b2>
<TiltMeSenpai> mostly thinking about the scope side, I guess we could do usb-dfu on the active probes but I don't know what firmware on them could possibly need updating
<agg>
on the scope side couldn't the scope manage updating the mcu firmware itself?
<agg>
if you chose carefully i guess you could bootload the probe firmware over the uart sbu connection anyway
<d1b2>
<TiltMeSenpai> yeah, there's lots of options there
<d1b2>
<david.lenfesty> I mean for manufacturability, using the cable as USB DFU is quite nice. You could pretty easily set up a jig that uploads fw over USB, resets the probe and then tests it automatically.
<d1b2>
<TiltMeSenpai> is that any better or worse than pogo pins?
<d1b2>
<david.lenfesty> I guess I thought it would be easier for low-volume production but i've never set up an actual production jig either so I have no idea
<azonenberg>
Yeah pogo pin swd would work fine for factory programming
<azonenberg>
more importantly though the probe mcu should basically never need updating
<azonenberg>
we're talking about something that is basically a uart to i2c/spi dac converter
<azonenberg>
make it work and never touch it again
<d1b2>
<j4cbo> heck, could even just run i2c over D+/D-
<d1b2>
<david.lenfesty> I mean we're doing UART over SBU so close enough
<azonenberg>
Still not thrilled about the SI on this link even with a short cable
<azonenberg>
it looks like there's a huge reflection from... somewhere
<azonenberg>
The bringup board is using an 0.225 / 0.125 mm diffpair which is... probably? 100 ohms impedance but i should probably double check
<azonenberg>
... oh i think i found it
<azonenberg>
Derp
<azonenberg>
The MEAD bringup board is referencing the signals to ground and the integralstick board references them to 2.5. there's decoupling caps on the integralstick but i dont see any for the return currents on the bringup board
<azonenberg>
So that is probably it
<azonenberg>
Which means we should see much nicer si on maxwell. If this is indeed what's going on
miek has quit [Ping timeout: 260 seconds]
miek has joined #scopehal
m4ssi has quit [Remote host closed the connection]