<tnt>
looks like you have one device operating at 1v8 connected to one using 3v3 ?
<d1b2>
<brainstorm> Oh, I thought I was driving 3.3V through port A?: glasgow run jtag-openocd --port A --pin-tck 0 --pin-tms 3 --pin-tdi 2 --pin-tdo 1 -V 3.3 -f100 tcp:localhost:5555?
<d1b2>
<brainstorm> You mean that the ESP32S2 jtag operates at 1.8V?
<tnt>
I'm not familiar with the esp32s2 but looking at your traces, you have mid level voltages ..
<d1b2>
<brainstorm> frantically googling "mid level voltages" and everything related to not appear as clueless as possible... learning... 😉
<tnt>
I mean ... look at your cyan trace, it's obvious you have like 0, 1 .. and 0.5 levels ...
<d1b2>
<Attie> depending on which device is talking, you may get this type of effect...
<d1b2>
<Attie> what are these signals?
<d1b2>
<brainstorm> They are supposed to be Glasgow's jtag_openocd applet communicating with the JTAG pins of a ESP32S2 IC.... jtag_probe does detect the Tensilica IC (ESP32S2), but OpenOCD complains about comms failures.
<d1b2>
<Attie> ok, but can you identify them - e.g: Yellow is TCK, etc...
<d1b2>
<Attie> ... what's the difference between yellow and cyan?
<d1b2>
<brainstorm> Ah, yeah, hold on... mapping the pins for you...
<d1b2>
<DX-MON> also, if you're telling Glasgow to drive a 1.8V device with 3.3V signals, then yeah.. it won't "hear" the answers because 1.8V is less than the Vhi of 3.3V CMOS logic.. hence "all 0's"
<d1b2>
<DX-MON> and you can damage the 1.8V device with overdriving it like that
<d1b2>
<Attie> this one is also a little concerning...
<d1b2>
<Attie> draw up the schematic for how the glasgow and ESP32 are wired (and share with us please)
<d1b2>
<Attie> read up on the ESP32 datasheet / module's documentation to see if it's running at 1.8v or 3.3v
<d1b2>
<Attie> and then take another run
<d1b2>
<Attie> I don't think yellow looks like TDO... I don't think any of Cyan / Yellow / Magenta are super "happy"
<d1b2>
<Attie> (based on the small signal on magenta, and midpoints on yellow / cyan)
<d1b2>
<DX-MON> if cyan is TDO, then it's got one hell of a lot of coupling from TCK
<d1b2>
<Attie> also @DX-MON is right - this could be damaging the target, or it could have already damaged the target, producing false results
<d1b2>
<brainstorm> @Attie Thanks! I'll do so immediately! @DX-MON switched to 1.8V, same effect, will capture traces but first I'll go for Attie's advice.
<d1b2>
<Attie> so if you have a second / known-good part, then once you've answered some questions, try on that
<d1b2>
<brainstorm> Yes, I have a couple more spares, I hope I've not fried it, good point.
<d1b2>
<brainstorm> ESP32's usually operate at 3V3 on all pins, I'm surprised it'd require 1V8
<d1b2>
<Attie> glasgow has some series resistors on the I/O (33R), so you should be limited to ~100mA at 3.3v... which while not a dead short, could still be damaging
<d1b2>
<DX-MON> yeah, the series term resistors are some seriously smart designing
<d1b2>
<DX-MON> 3.3V-1.8V = 1.5V, so 45mA ish
<d1b2>
<DX-MON> not great.. might still damage stuff.. but at least not a dead short
<d1b2>
<brainstorm> > The JTAG I/O pins all are powered from the VDD_3P3_RTC pin (which normally would be powered by a 3.3 V rail) so the JTAG adapter needs to be able to work with JTAG pins in that voltage range."
<d1b2>
<brainstorm> Fear of something being cooked on that board has been slightly lowered.
<d1b2>
<brainstorm> @agg, no I switched back to 3.3
<d1b2>
<Attie> ok, it's a WROVER module on a board, which is 3.3v
<d1b2>
<Attie> please disconnect all signals from the target, and take a capture... I don't think yellow / cyan should be the same like that
nCrazed has left #glasgow [#glasgow]
<d1b2>
<brainstorm> You mean only probing what the Glasgow is sending? Sure!
<d1b2>
<Attie> correct, no ESP32 attached
<d1b2>
<Attie> you could try reducing the frequency a lot, e.g: -f 1... though i don't expect that to make a huge difference
<d1b2>
<brainstorm> There's always that weird message from OpenOCD stating that: > Info : remote_bitbang driver initialized > Info : This adapter doesn't support configurable speed
<d1b2>
<brainstorm> So I'm not sure if that's actually part of the problem?
<d1b2>
<Attie> probably because glasgow asserts the frequency (as part of the command line)
<d1b2>
<DX-MON> it's not as you're configuring that with the -f parameter on the Glasgow command lien
<d1b2>
<DX-MON> *line
<d1b2>
<brainstorm> Oscilloscope only attached to Glasgow
<d1b2>
<brainstorm> Now yellow (TDO), looks super weird :/
<d1b2>
<Attie> right... that's "better", but there's still lots of coupling between cyan and yellow
<d1b2>
<Attie> are the wires twisted together / running in parallel for a long stretch?
<d1b2>
<brainstorm> Not twisted, dupont wires as they come out from the box... will twist and/or intersperse them... tomorrow though, 2am here in Australia XD
<d1b2>
<brainstorm> Thanks a ton for all the advice, this is gold! 🙂
<d1b2>
<Attie> try to physically separate them as much as possible
<d1b2>
<Attie> glasgow's pin is probably Hi-Z, so the coupling isn't super concerning, but it's not great
<d1b2>
<brainstorm> Will catch up with your CAN stream, btw, hope it's recorded 😉
<d1b2>
<Attie> when you connect to ESP32 again, it shouldn't mirror
<d1b2>
<Attie> (like it was)
<d1b2>
<Attie> oo, yes - it'll be available on twitch for a while, and archived on youtube / diode.zone
<d1b2>
<brainstorm> Why do you think Cyan/Yellow were the same? Super intrigued :_/
<d1b2>
<DX-MON> edits don't show up on IRC FYI, so please try not to make them
<d1b2>
<DX-MON> most probably because one of the signals (TDO) was high-Z and the wire was running very close to TCK (as in directly next to for almost the entire length)
<agg>
you probably need to zoom in more on the scope to really see what's happening
<d1b2>
<DX-MON> so any signal on TCK was tightly coupling over to TDO
<agg>
at the timescale you're at, all we can see is that a burst of activity happened
<d1b2>
<brainstorm> But that coupling... shouldn't they have different amplitudes then?
<d1b2>
<DX-MON> which if you scope is showing that up.. that is bad from a perspective of OOCD trying to interpret the answers from the chip
<d1b2>
<DX-MON> depends on how tightly coupled the signal is
<d1b2>
<DX-MON> agg is right though.. to see what exactly is going on you'd need to zoom in and focus on a smaller segment of the trace
<d1b2>
<brainstorm> Alright, more battles tomorrow, thanks again folks! 😉
<agg>
maybe just connect more/better ground cables between the two, heh
<agg>
i doubt crosstalk is really causing all the problems here
<agg>
always very hard to debug this sort of thing remotely though
<d1b2>
<DX-MON> agreed agg.. but it's also something to investigate
<d1b2>
<DX-MON> more and better grounding is always good though
<agg>
i missed it earlier, what's the colour/channel to signal key?
<d1b2>
<DX-MON> (shame coax is super expensive to come by)
<agg>
oh I got it
<agg>
actually i didn't get it, those were wire colours not scope
<agg>
anyway yea try again tomorrow, sometimes it just works after sleep
<d1b2>
<DX-MON> Light-blue: TCK, Yellow: TDO, Dark Blue: TDI, Green: TMS - this is the scope key
<agg>
thanks
<d1b2>
<zipferli> i don't think is crosstalk, there are 20ms long "static" parts in the signal that are 1:1 identical, at least from the screenshots. Also the ~1.8V level is a little suspicious to me, could very well be some kind of short between yellow and cyan and 2 output stages trying to force differing levels on one another? At least that's exactly what it looked like last time I had that happen to me on an STM32
<d1b2>
<DX-MON> I think "Green" there is a misreading of magenta (colourblindness?)
<agg>
zipferli: yea, i'm with you, or just maybe no/usb-only ground connection earlier
<agg>
i wonder if the glasgow jtag app could clear it up, just using it to scan the chain and read idcodes etc
<d1b2>
<DX-MON> interesting thoughts for @brainstorm when they wake again
<d1b2>
<DX-MON> I agree, having Glasgow locally do an IDCode scan of the chain is a good more self-contained test that's easier to control the parameters on
<d1b2>
<DX-MON> it'll also be interesting to see a post-ground-correction sampling of what's happening on TDO
<d1b2>
<Attie> i agree that it's not 100% cross talk / coupling... but is likely a short between the signals somewhere
<d1b2>
<Attie> i should have been clear for @brainstorm - removing the ESP32 from the equation removes a potential source of that short
<d1b2>
<zipferli> It's probably a bit of a long shot, but looking at the picture of the probing setup and P39/P40 (which should be Cyan and Yellow) being right next to each other, I'd probably take the time to double check its not just the probe shorting the two pins together at the pinheader.
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
yorick has quit [Ping timeout: 260 seconds]
yorick has joined #glasgow
egg|anbo|egg_ has quit [Read error: Connection reset by peer]
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
<_whitenotifier>
[GlasgowEmbedded/glasgow] electroniceel pushed 1 commit to wip-revC3-hardware [+0/-0/±1] https://git.io/JtfKR
<_whitenotifier>
[GlasgowEmbedded/glasgow] electroniceel cce7728 - revC3: connect the 3v3 pin of the LVDS connector with a second via
modwizcode has joined #glasgow
<d1b2>
<DX-MON> for the Discord folks: I am about to drop into the video-chat/#video-text channels and do a grunt stream working on the 3 Glasgow addon boards I need/want to finish - anyone is welcome to join and watch or even chat
GNUmoon has quit [Ping timeout: 240 seconds]
GNUmoon has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
<d1b2>
<Greg> I haven't been tracking the INA233 issue on the revC2 hardware too closely. Is this issue now solved in firmware? Or is there a recommended hardware mod I should apply to some revC2 boards I've built?
GNUmoon has quit [Remote host closed the connection]