<d1b2>
<Attie> @brainstorm ah, of course (sorry)... in that case you've got a 10k pull... confirm with a scope, if the rising edges are too soft / rounded at higher speeds, then you'll see issues like you're reporting
<d1b2>
<Attie> a smaller value than 10k would be good... adding a second (discrete) in parallel with the on-board pull could be done (but do the math), or disable the onboard, and use just a discrete
egg|anbo|egg_ has joined #glasgow
robbi53 has joined #glasgow
robbi5 has quit [Read error: Connection reset by peer]
robbi53 is now known as robbi5
fibmod has quit [Ping timeout: 256 seconds]
fibmod has joined #glasgow
G33KatWork has quit [Ping timeout: 256 seconds]
G33KatWork has joined #glasgow
jstein has quit [Ping timeout: 246 seconds]
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel has joined #glasgow
_whitelogger has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter_ is now known as PyroPeter
<d1b2>
<brainstorm> @Attie How much better do you think the speed improvement with lower than 10k values will be? Trying to manage expectations before putting in a potentiometer and try different settings :)... 20% faster, 200% faster?
_whitelogger has joined #glasgow
egg|anbo|egg_ has quit [Remote host closed the connection]
_whitelogger has joined #glasgow
<d1b2>
<brainstorm> I just set the Glasgow to 6000kHz (not sure if it's reasonable in this janky dupont wire setup of mine but I've seen that this is a typical FTDI JTAG probe speed)... then I'm capturing those oscilloscope shots as the current Glasgow pullup 10k "default" as a baseline... the waveforms do look a bit round at 10us scale, then: 1) I don't know if that's reasonable since I have no frame of reference for what looks good or bad (as in how fast should the
<d1b2>
rising edge go up and look like at 10us timescale?). 2) I don't know which physical resistor values would "correct" this properly giving me more acceptable speed? 3) Would using a pot be a no-no in this setup or it's better to use fixed resistors?... if the latter is true, TH are acceptable or just SMD?
<d1b2>
<brainstorm> It's interesting that some edges rise fast and others are soo slow curve :-S.... I'd have expected a all-or-nothing scenario instead.
<d1b2>
<brainstorm> *all-or-none
sorear has quit [Ping timeout: 264 seconds]
sorear has joined #glasgow
nicoo has quit [Remote host closed the connection]
nicoo has joined #glasgow
<d1b2>
<rwhitby> @brainstorm likely that some edges are driven high and some are put to hi-z and so float high due to your pullup
<d1b2>
<rwhitby> @brainstorm can you capture TCK alongside TDO so we can see how the setup and hold is looking?
bluel_alen has left #glasgow [#glasgow]
alen has joined #glasgow
trh has quit [Ping timeout: 256 seconds]
trh has joined #glasgow
PyroPeter has quit [Ping timeout: 256 seconds]
fibmod has quit [Ping timeout: 256 seconds]
PyroPeter has joined #glasgow
fibmod has joined #glasgow
_whitelogger has joined #glasgow
bvernoux has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
<jpa->
that's a loooong rise time for the pull-up.. why is it even using pull-up, i thought JTAG didn't even need pull-ups and was always strongly driven?
<d1b2>
<brainstorm> Without the Glasgow pullup it looked like this and it just didn't work.
<d1b2>
<brainstorm> Is it possible to tweak the pullup resistor values via software in Glasgow instead of going for a physical one?
<jpa->
yellow is TDO?
<d1b2>
<brainstorm> Yes
<jpa->
and TDO is the output from the card you are trying to program?
<d1b2>
<stefandeml> Hello everybody, I think using Glasgow for ESP32 JTAG debugging is a fantastic usecase.... and if my Glasgow would already have been arrived, then it is the first thing I would have tried as well. Can somebody maybe elaborate why these pulls are needed in the first place? And why not an extant pull can be used? I also don‘t really understand where the performance limitation is coming from. 100MHZ mentioned on the campaign page should plenty ...
<d1b2>
are these pulls controlled via i2c? Sorry for the beginner questions, but I really like the use-case!
<d1b2>
<stefandeml> @brainstorm shout-out for the work so far!
<d1b2>
<brainstorm> @jpa- , yes the TDO on Glasgow is connected to the ESP32S2 TDO line, if I understood your question right.
<jpa->
brainstorm: have you double-checked that your ground wire between glasgow and the ESP32 board is ok?
<jpa->
i would measure with multimeter to make sure
<d1b2>
<stefandeml> Yeah, I already checked this out. Still don‘t really understand the complexity on the Glasgow Side. But need to get more familiar... 🙂
<d1b2>
<brainstorm> @jpa- I just measured ground between those (~0 ohms) and added extra GND wires for good measure between the board and Glasgow, same effect.
<d1b2>
<brainstorm> @stefandeml "And why not an extant pull can be used?"... never heard of "extant pull", to be honest, how would the wiring look like if you built this?
<d1b2>
<stefandeml> Sorry, autocomplete.. I was about to write „external“
<d1b2>
<brainstorm> Ah, convenience... the board claims to have configurable pulls, so I just went for software instead of putting more messy wires in my setup.
egg|anbo|egg_ has joined #glasgow
egg|anbo|egg__ has joined #glasgow
egg|anbo|egg_ has quit [Ping timeout: 256 seconds]
egg|anbo|egg__ has quit [Remote host closed the connection]
egg|anbo|egg_ has joined #glasgow
<d1b2>
<brainstorm> Now I saw the light... that connector is to accomodate pull resistors!
<d1b2>
<Attie> these edges are far too slow... while I agree, that TDO shouldn't need a pullup, perhaps there is something odd about the ESP32? (I'll try to look later)
<d1b2>
<Attie> the glasgow offers constant 10k pull up / 10k pull down / no pull
<d1b2>
<brainstorm> And now I see @Attie's point on calculating the parallel resistor
<d1b2>
<brainstorm> As in putting a through hole right there, nice!
<d1b2>
<Attie> I think you'll want to disable the glasgow onboard pull, and swap for a smaller value - perhaps ~2.2k as a starting point
<d1b2>
<brainstorm> Ah, good point, yeah
<d1b2>
<Attie> yes indeed! you can add parallel pulls there
egg|anbo|egg_ has quit [Remote host closed the connection]
<d1b2>
<brainstorm> But hold on, if I want to do a pull-up, I need to enable that 10k anyway, right? If I disable the software pulls and chuck a 2.2k there it'll not act as a pull-up since the default is "no pull", right? Therefore enable that 10k and calculate the resistor needed to reach 2.2k in parallel?
<d1b2>
<Attie> yes I think so... it's adjacent to all the GND pins
<d1b2>
<Attie> yep - Vio
<d1b2>
<brainstorm> Ok, pulling that up via a through hole 2k2 resistor... I find it weird that this is fine when there are those two 2k2 pulled down to GND? :/
<d1b2>
<Attie> you're pulling the I/O line up to Vio (not the other way round)... the 2.2k resistors to Gnd are likely to bring the supply rail down quickly on power off (you can ignore them here)
<d1b2>
<brainstorm> Gotcha, on it, thanks! 😉
<d1b2>
<brainstorm> It'll have to be a 4k7 instead, couldn't find 2k2 around... not proud of the setup either, but should do what you suggest, I guess.
<d1b2>
<brainstorm> Right away the TDO waveform looks a bit better and even the oscilloscope trigger seems more stable, looking promising 🙂
<d1b2>
<brainstorm> ... same "logic" result and timeouts as before, but I'm feeling optimistic, will lower from 4k7 to ... some other lower value I have around :/
<d1b2>
<thomasflummer> two 4k7 in parallel is pretty close to a 2k2...
<d1b2>
<brainstorm> I gave it a go with 1k, looking good... same timeout errors though :/
<d1b2>
<brainstorm> Same effect... the 1k waveform looks faster rise & better... I guess that the next step would be to tackle the TCK coupling via twisting and better GND handling perhaps?
<d1b2>
<brainstorm> Same effect == warning: unrecognized item "timeout" in "qSupported" response and Remote replied unexpectedly to 'vMustReplyEmpty': PacketSize=4000;qXfer:memory-map:read+;qXfer:features:read-;qXfer:threads:read+;QStartNoAckMode+;vContSupported+ from GDB
<d1b2>
<brainstorm> I don't quite understand why there's this line when TDO is supposedly high, though? 🤔
<d1b2>
<brainstorm> Anyway, play time is over for me though... there's #dayjob tomorrow morning, so see you folks tomorrow, eager to read suggestions and learn further about all this 😉
<d1b2>
<martinr> almost finished assembling my glasgow, but the 1.2v reg seems to be outputting 0.5v
<d1b2>
<martinr> anyone know why this might be? (apart from a dead regulator)
<d1b2>
<martinr> resistance between 1.2v and gnd is 5k, so no short on the rail
<d1b2>
<Attie> @brainstorm "I don't quite understand why there's this line ..." I'd suspect it's multiple triggers in the screenshot - try a single capture
<d1b2>
<Attie> @martinr have you confirmed the feedback divider is correct and with no shorts?
<d1b2>
<martinr> not quite sure what you mean? i dont think this regulator has a feedback pin
<d1b2>
<martinr> its fixed voltage right?
<d1b2>
<Attie> ah, apologies - you're quite right
<d1b2>
<Attie> what do you have populated, and what's the current draw via the USB connector?
<d1b2>
<martinr> everything to do with the power supply is populated (1.2v reg,3.3v, power rail sequencer, overcurrent protection ic), as well as the fx2, the fpga and most of the i/o circuitry
<d1b2>
<martinr> ill check current draw now
<d1b2>
<martinr> current draw stabilises to 22ma after a few seconds
<d1b2>
<martinr> since NC and OUT are connected by pcb traces, maybe NC has 0.5v on it and OUT isnt properly soldered?
<d1b2>
<martinr> yeah i desoldered it to check, and the out pin is entirely missing from the ic lol
<d1b2>
<Attie> ! O_O
<electronic_eel>
@martinnr pin? isn't the regulator in a dfn package without pins? or which glasgow rev are you building?
jstein has joined #glasgow
<d1b2>
<martinr> its revC1
<d1b2>
<martinr> regulator is a wson package
<d1b2>
<martinr> theres no 'leads' on the package but im not sure what else to call them apart from pins]
<d1b2>
<DX-MON> they're referred to as lands or pads usually
<d1b2>
<DX-MON> pins is acceptable though
null_ptr has quit [Ping timeout: 256 seconds]
ptr_0x0001 has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
bgianf_ has quit [Ping timeout: 256 seconds]
G33KatWork has quit [Ping timeout: 256 seconds]
G33KatWork has joined #glasgow
GNUmoon has joined #glasgow
fibmod has quit [Ping timeout: 256 seconds]
trh has quit [Ping timeout: 256 seconds]
trh has joined #glasgow
fibmod has joined #glasgow
bgianf has joined #glasgow
ExeciN has joined #glasgow
bvernoux has quit [Quit: Leaving]
<d1b2>
<stefandeml> Quickly follow up question on that drawing: shouldn’t the slowdown be constant for all shifts? Why is only the first one delayed by the 10k in that case?
<d1b2>
<Attie> I can only presume the ESP32 is driving the pin low, and (for currently unknown reasons) is also either driving the pin high, or putting it hi-z...
<d1b2>
<Attie> honestly, it doesn't make much sense to me right now, and I think reading into the ESP32's JTAG interface might be the best next step
<d1b2>
<Attie> also confirming that the application isn't changing the pin config
egg|anbo|egg_ has joined #glasgow
<agg>
before thrownig openocd
<agg>
oops, sorry, up-enter on wrong window
modwizcode has joined #glasgow
egg|anbo|egg_ has quit [Remote host closed the connection]
<d1b2>
<Attie> but have a read through, and perhaps it would be worth putting a 10k pull up on that too (the Saloa board doesn't do anything with that pin)
<d1b2>
<brainstorm> On TDI you mean?
<d1b2>
<brainstorm> Or perhaps all the JTAG pins?
<d1b2>
<Attie> yes, TDI - it's used as a bootstap pin (i.e: the value is sampled at power up, and this changes the configuration... 1.8v vs 3.3v as you pointed out)
<d1b2>
<Attie> ... I also noticed that the default pin state of TDO is "MTDO", and the type is listed as O/T
<d1b2>
<Attie> (this datsheet also quite explicitly lists these pins as 3.3v, so i think the bootstrap config is related to only ESP32 - not ESP32-S2)
<d1b2>
<Attie> @marcan any chance you have the accurate translation of the text on the back handy? "it can do anything / it can be anything"
<d1b2>
<Attie> i'd like to put it in my slides for FOSDEM
<d1b2>
<Attie> perhaps the name of the source too?
<d1b2>
<brainstorm> OT: After a quick test I just found out that I can drive the applet up to 10MHz with my super crappy setup and not "lose a beat" (out of the 20/26MHz max advertised on the page above)... I bet I can do better with proper wiring (via a board/connector).
<d1b2>
<Attie> @brainstorm - if you find detailed docs on the behaviour of the JTAG interface, please let me know... I can't see a good reason for TDO to be put Hi-Z, and it seems to be "very poorly" (not) documented