egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
<d1b2>
<icb> Unless I'm looking at an out of date schematic, I think there are two GPIO pins left unconnected on the FX2, PD1/FD9 and PD7/FD15. Couldn't you pin strap one of those to signal prototype boards and include a big "This is prototype hardware" warning in the CLI?
uovo has quit [Ping timeout: 268 seconds]
<whitequark>
icb: those will no longer be unconnected on revD (in fact they have been freed for that purpose)
<d1b2>
<icb> Aah, ok
uovo has joined #glasgow
<cyrozap>
If we're still brainstorming things to put in the silkscreen to replace "Glasgow" in the dev/wip branch board, I'm partial to "owGglas". Pros: 1) It's an anagram, so it's the same number of characters and will render to the same width as "Glasgow", even in a non-monospaced font. 2) It sounds like "Ow, glass!" so you know not to touch it. Cons: 1) "owGglas" both looks and sounds dumb :P
<whitequark>
ha, i like it
<d1b2>
<xabean> as someone who has stepped on glass, a work-in-progress design "DANGER, DANGER WILL ROBINSON" "Ow, glass!" is fitting :P
<d1b2>
<esden> I like the "owGglas" anagram too. 🙂
nicoo has quit [Ping timeout: 240 seconds]
<d1b2>
<xabean> inb4 someone tries to say "but it's two Gs!" "ow-goggles" or "o-guh-glas" (like legolas)
DarthCloud has quit [Ping timeout: 240 seconds]
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #glasgow
DarthCloud has joined #glasgow
nicoo has joined #glasgow
nicoo has quit [Remote host closed the connection]
nicoo has joined #glasgow
egg|laptop|egg_ has quit [Read error: Connection reset by peer]
<d1b2>
<DX-MON> pronouncing as "o-guh-glas" still gives the right idea here as that sounds like very smelly glass and ergo "dirty" or "unfit for general consumption".. which is the idea in a wip/dev monica..
<d1b2>
<DX-MON> I like the anagram, it's neat
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
egg|laptop|egg has quit [Remote host closed the connection]
<d1b2>
<brainstorm> Hello folks, I'm playing with a couple of JTAG Glasgow applets against an ESP32S2 Saola-1 dev board: jtag-probe and jtag-pinout with the following arguments and (non) results: $ glasgow run jtag-probe --port A --pin-tck 0 --pin-tdo 1 --pin-tdi 2 --pin-tms 3 -V 4 scan I: g.device.hardware: device already has bitstream ID 323f35a8e0462bc4c48448b858bf1aaf I: g.cli: running handler for applet 'jtag-probe' I: g.applet.interface.jtag_probe: port(s) A
<d1b2>
voltage set to 4.0 V I: g.applet.interface.jtag_probe: shifted 0-bit DR=<> I: g.applet.interface.jtag_probe: shifted 0-bit IR=<> W: g.applet.interface.jtag_probe: DR segmentation discovered no devices $ glasgow run jtag-pinout --port A --pins-jtag 0,1,2,3 -V 3.3 I: g.device.hardware: building bitstream ID b7ae79d75f04c840bfe4f2becf1cf48e Warning: Wire top.$flatten\i2c_target.\bus.$verilog_initial_trigger has an unprocessed 'init' attribute. Warning: Wire
<d1b2>
top.$verilog_initial_trigger has an unprocessed 'init' attribute. I: g.cli: running handler for applet 'jtag-pinout' I: g.applet.interface.jtag_pinout: port(s) A voltage set to 3.3 V I: g.applet.interface.jtag_pinout: detecting pull resistors I: g.applet.interface.jtag_pinout: pull-L: A3 I: g.applet.interface.jtag_pinout: detecting TCK, TMS and TDO W: g.applet.interface.jtag_pinout: no JTAG interface detected I believe I've connected the wires well (according
<d1b2>
<brainstorm> Where would you poke next if you were in my fingertips? 🙂
<whitequark>
brainstorm: please use pastebin, this channel is bridged to IRC and your paste looks unreadable
<d1b2>
<brainstorm> Argh, sorry, addressing...
<whitequark>
esden: btw, do you think we could make the bot do that automatically? this doesn't seem like a hard problem
<cyborg_ar>
that would be a great idea
<cyborg_ar>
what could be the heuristic? newlines in the message?
<d1b2>
<brainstorm> Sorry for the garbled text. I guess IRC gateway doesn't pick up updates, but I've changed it to https://pastebin.com/CgUuuHVL for those over... freenode?
<d1b2>
<Greg> @brainstorm Are your pins connected correctly on the Glasgow side? The picture is not super clear so I'm inferring. But it looks like you might have Grey on Vsense, Purple,Blue,Green on GND, and Brown on io4.
<d1b2>
<brainstorm> Grey, purple, blue, green on 0,1,2,3 port A
<d1b2>
<brainstorm> Then Brown on GND, going to the ESP and oscilloscope probe ground clips.
<d1b2>
<brainstorm> Then on the ESP32S2 side, the same color sequence on pins 39, 40, 41 and 42.
<d1b2>
<Greg> It's just that brown looks like it's on the inner row of pins, not the outer ones.
<d1b2>
<Greg> Can you just confirm that it's matching this pinout.
<d1b2>
<brainstorm> Thanks Greg! Big fan of your stuff, btw 🙂
<d1b2>
<Greg> np, it's nice when it's an easy fix. Sometimes a second set of eyes is all you need 😛
<whitequark>
cyborg_ar: maybe a code block with more than 1-2 lines
<whitequark>
brainstorm: whatcha doing?
<d1b2>
<brainstorm> Ah, I was disappointed by the fact that my default go-to debug probe, the STLinkv2, was not supported as JTAG probe for the ESP32 and I then I remembered I had a Glasgow :D But now it seems that it'd have to wrestle a bit more since the Espressif OpenOCD does not seem to support remote_bitbang?: https://pastebin.com/EpZ8xStB
<d1b2>
<brainstorm> I'm running glasgow run jtag-openocd --pin-tck 0 --pin-tms 3 --pin-tdi 2 --pin-tdo 1 -V 3.3 tcp:localhost:2222 on another terminal.
<whitequark>
well that seems not very nice of espressif
<whitequark>
can probably rebuild it?
<d1b2>
<brainstorm> Yeah, those were my next steps... fearing the custom patching that they might have put in there and which version/how hard to merge it'd be...
<whitequark>
they will go away at one point, there is a bunch of annoying compatibility concerns that i don't really want to go into
uovo has quit [Ping timeout: 264 seconds]
uovo has joined #glasgow
<d1b2>
<brainstorm> Hm, interesting, enabling REMOTE_BITBANG on config.h still fails but there's a mysterious jtag_esp_remote debug interface listed in the error now... https://pastebin.com/42g1ynde
<whitequark>
brainstorm: i think maybe their impl is a bit more efficient?
<whitequark>
not... not that it really matters, it goes through slow as heck python code anyway
<whitequark>
it's like slightly more elegant but in a pointless way. i can see myself implementing that and then deciding to not throw it away in favor of remote_bitbang heh
<whitequark>
the only thing i see that could actually matter is queueing
<whitequark>
and i'm not awake enough to have a good intuition for whether that matters or not
<whitequark>
in any case, they should just enable normal remote_bitbang anyway.
<d1b2>
<brainstorm> I cannot see things like Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1) as the docs state though :/
<whitequark>
brainstorm: it is definitely not compatible with normal remote_bitbang
<whitequark>
it uses a protocol completely different in every aspect
<whitequark>
brainstorm: ok so like... what's the problem with using normal remote_bitbang
<d1b2>
<brainstorm> I enabled the option on config.h and it didn't enable it, need to check the source and see if they actually substituted one for the other entirely
<whitequark>
lemme look at this
egg|laptop|egg has quit [Remote host closed the connection]
<whitequark>
brainstorm: i could build their master branch with remote bitbang