06:21 <d1b2> <brainstorm> Are there any docs/examples on how the configurable pull-ups/downs work on the Glasgow? They are mentioned in the README.md as "independent direction control and independent programmable pull-up/pull-down resistors", but looking at the jtag-probe applet I can follow up up to multiplexer.claim_interface() ... and the self-test applet seems to try different configurations of pull-ups/downs but I'm not 100% sure how to call it from the jtag_openocd

06:21 <d1b2> applet. On the self-test applet I found: pull_high = {x for x in range(16) if bits_oe & (1 << x) and bits_o & (1 << x)} ... but it's unclear (to me) what o and oe mean... output & output enable? 😒

06:22 <d1b2> <brainstorm> I'll go and read an nmigen tutorial meanwhile, need more context/knowledge about how this all works 🙂

06:39 <d1b2> <rwhitby> @brainstorm That expression says add the bit number (0 to 15) into the pull_high python Set if the corresponding bit is set in both the bits_oe and bits_o bitmasks (i.e. is the pin both an output and the output enable is set). So pull_high is effectively a list of the pins that need to be pulled high.

07:21 <d1b2> <brainstorm> Thanks @rwhitby . Yes, I did understand the context and expression and the fact it pulls up all 16 pins... I'm just confused as to how to pull TDO high on jtag_openocd given the examples from other applets... so I need to understand the different Glasgow classes/modules a bit better to do that I reckon.

07:22 <d1b2> <rwhitby> @brainstorm no worries, did not mean to explain things you already knew 🙂

07:23 <d1b2> <rwhitby> I would expect that you can just add the pin number for TDO into that pull_high set. But don't trust my word, cause I've only had a Glasgow for 1 day now 🙂

07:26 <d1b2> <rwhitby> somewhere I guess you'd add a call to device.set_pulls with the right ports and low and high sets.

07:26 <d1b2> <rwhitby> (with tdo pin in the high set)

07:29 <d1b2> <rwhitby> either in the build or the run functions. not sure which, probably run?

07:31 <d1b2> <rwhitby> maybe in async def run()..

07:33 <d1b2> <rwhitby> the i2c-initiator has an example of setting pulls in the run function

07:34 <d1b2> <brainstorm> Ah, yes, so it was indeed a .claim_interface() parameter, thanks!

07:35 <d1b2> <rwhitby> yep, just gotta work out how to retrieve the pin number for tdo

07:36 <d1b2> <brainstorm> Now I see how, thanks for pointing it out 🙂

07:39 <d1b2> <brainstorm> Fairly easy, actually, implemented!

07:42 <d1b2> <Hardkrash> @brainstorm I appreciate on scope screenshots is when the channels are labeled on the scope, it helps avoid signal confusion.

07:43 <d1b2> <brainstorm> Yeah, sorry about that, thought about it after the fact too :_/

07:43 <d1b2> <Hardkrash> Is there a way to do a bus-holder topology?

07:43 <d1b2> <Hardkrash> https://en.wikipedia.org/wiki/Bus-holder

07:43 <d1b2> <brainstorm> I'm... definitely not an expert on Glasgow, I don't know if that's possible, sorry 😒

07:56 <d1b2> <brainstorm> @Attie, you were absolutely right, the pullups in Glasgow helped a lot with the waveform, thanks! 😉 ... would my pullup changes be accepted via PR? Is it interesting with other JTAG cases or it's just me having problems with this?

07:56 <d1b2> <brainstorm> https://cdn.discordapp.com/attachments/613461005392936961/799909997089128458/RigolDS21.png

07:56 <d1b2> <brainstorm> https://cdn.discordapp.com/attachments/613461005392936961/799910000495296522/RigolDS22.png

07:56 <d1b2> <brainstorm> https://cdn.discordapp.com/attachments/613461005392936961/799910003292241960/RigolDS23.png

07:59 <d1b2> <brainstorm> Now, I think I'll connect another ESP32S2 part to discard that the current weird errors are not a result of a partly fried IC or something, namely: Warn : Unknown ESP32-S2 chip revision (0x3f400074)! Warn : Failed to get flash mappings (-4)! Error: Invalid stub!

08:00 <d1b2> <Hardkrash> Looking at glasgow it might be possible at lower data rates, but it depends on the update rate of the Pull up/pull down register. A bus keeper configuration would have to update pull down on 0 in and pull up on 1 in. As the I2C bus is driven by the FX2 it is unlikely that it is fast enough. A bus-keeper add-on would have to be the solution for faster signals.

08:01 <d1b2> <brainstorm> Thing is that OpenOCD eventually says that Info : This adapter doesn't support configurable speed ... so even if I put Glasgow and OpenOCD at 100kHz (current default on both sides), I'm not entirely sure this is respected at all 😕

08:02 <d1b2> <Hardkrash> That signal is very clean now, nice touch on having the label show the configuration.

08:02 <d1b2> <brainstorm> You asked, I deliver 😛 😛

08:08 <d1b2> <brainstorm> I've put the code changes on the espressif-openocd issue for now, but I might open a PR if there's interest: https://github.com/espressif/openocd-esp32/issues/135#issuecomment-761525207 I'll tackle the speed problem next... which speed you'd reckon is reasonable to not run into those kind of errors @Hardkrash ? Something like 20Khz? Less than that?

08:39 <d1b2> <Hardkrash> I don't know that the turnaround time would be, I have no hardware yet. But honestly, the bus-keeper was just a thought for a generic way to stabilize signals without forcing a pull up nor down. The signals look a lot cleaner with just the pull-ups enabled.

08:40 <d1b2> <Hardkrash> Or am I misinterpreting your question on frequency?

08:58 <electronic_eel> @hardkrash I think having too slow bus keepers is worse than having none, because they will pull in the wrong direction for some time

08:58 <electronic_eel> so i'm skeptical if this can be done with the i2c connected pulls on glasgow

09:00 <electronic_eel> but brainstorms jtag won't use that many of the port pins. so doing keepers with fpga-connected port pins should entirely be possible. you'd just have to connect these pins through resistors to the signals

09:03 <electronic_eel> another reason why the i2c connected pulls won't work well for this is that the fpga isn't designed to be initiator on the internal i2c (i2c multi initiator = bad)

09:04 <electronic_eel> so the commands would have to go through usb to the python program, which would add way more latency, or be somehow done in the firmware on the fx2. but the fx2 doesn't know about the current pin states, so it would have to query the fpga for these first...

09:27 <d1b2> <Hardkrash> Yea, the bus-keeper would have to be from the FPGA via a spare pin or an external IC. Even if the FPGA could initiate the I2C for the pull up/pull-down to act as a bus keeper it would probably be far too slow for reasonable communications. I didn't think about the using a spare IO pin and could be made combinational logic. I was thinking that this would be a more general purpose application and probably for lower speed signals. The spare pin as a

09:27 <d1b2> keeper is probably the best option without an add-on board. And even overkill/misapplication, as long as TDO can be idle high.

10:34 <d1b2> <brainstorm> You were right folks, setting the --freq to 500khz (instead of the default 100kHz for that Glasgow applet) fixed the thing!: https://github.com/espressif/openocd-esp32/issues/135#issuecomment-761526636

10:37 <d1b2> <Attie> @brainstorm well done! I'm surprised that the wrong speed caused it to bail out (rather than just report and run slower)

10:37 <d1b2> <Hardkrash> Fantastic! and good night!

10:48 <d1b2> <brainstorm> Might be too slow for VSCode DAP server though (it seems to take too long to enumerate the flash mappings), sigh... what a rabbit hole XD

10:48 <d1b2> <brainstorm> https://cdn.discordapp.com/attachments/613461005392936961/799953222311084032/Skarmavbild_2021-01-16_kl._21.46.02.png

10:49 <d1b2> <brainstorm> But after those timeouts it works fine

10:49 <d1b2> <brainstorm> https://cdn.discordapp.com/attachments/613461005392936961/799953376233521182/Skarmavbild_2021-01-16_kl._21.48.54.png

10:50 <d1b2> <brainstorm> Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1003). Workaround: increase "set remotetimeout" in GDB

10:50 <d1b2> <brainstorm> Increasing that...

11:01 <d1b2> <brainstorm> I wonder what could be made on top of all this to make it a bit more reliable?: https://pastebin.com/nDCfRyY7

11:01 <d1b2> <brainstorm> Because it does end up working fine after it establishes connection... it just takes a bit for that connection to happen.

11:06 <d1b2> <brainstorm> It takes exactly 20 seconds to get a (gdb) prompt back after the target remote :3333 and the editor is bailing out at 10 seconds without retrying, makes sense...

11:22 <d1b2> <brainstorm> And stepping itself is really slow...as in 20 to 30 seconds per GDB step (next) :_S ... oh welp, time to go for a ESP-Prog board I guess, I'm out of ideas right now 😒

11:35 <d1b2> <brainstorm> I would have totally preferred to have my JTAG probe via Glasgow because I don't like FTDI's for several reasons, even if they are dirt cheap: https://medium.com/@manuel.bl/low-cost-esp32-in-circuit-debugging-dbbee39e508b

11:57 <d1b2> <Attie> bitbang JTAG probably will be pretty slow... have you tried turning the speed up, or does that result in the same error?

11:57 <d1b2> <Attie> have you tried patching it to just carry on if it can't change the speed?

12:15 <d1b2> <brainstorm> Speeding it up from 500kHz to 1000Khz yields the same results in errors and timing... surpisingly? The LED on the Glasgow blinks faster though XD

12:17 <d1b2> <brainstorm> at 2000kHz seems to be slightly faster, I'll keep poking a bit more...

12:19 <d1b2> <brainstorm> But yeah, at higher speeds it seems to loose some packets/reliability anyway: Some Error: GDB missing ack(2) - assumed good and Warn : negative reply, retrying show up.

12:20 <d1b2> <brainstorm> The OpenOCD log section that takes the longest right after target remote :3333 is the enumeration of flash stuff, i.e: Info : Flash mapping 1: 0x20020 -> 0x40080020, 73 KB ... I wonder if I can disable that without repercussions.

12:27 <d1b2> <brainstorm> Hah, the init/reset/halt does go much faster without configure_esp_workarea and configure_esp_flash_bank on OpenOCD's target definition (target/esp32s2.cfg) but then when setting breakpoints: Cannot access memory at address 0x400852d4

12:29 <d1b2> <brainstorm> And disabling those flash-checking OpenOCD routines is still not fast enough for the ESP-IDF VSCode extension

12:29 <d1b2> <brainstorm> https://cdn.discordapp.com/attachments/613461005392936961/799978731862491166/Skarmavbild_2021-01-16_kl._23.29.08.png

12:30 <d1b2> <brainstorm> (different error than the previous VSCode timeout one)

12:36 <d1b2> <brainstorm> @electronic_eel : Your comments on "so the commands would have to go through usb to the python program, which would add way more latency, or be somehow done in the firmware on the fx2. but the fx2 doesn't know about the current pin states, so it would have to query the fpga for these first..." ... so you reckon that a faster JTAG implementation on the Glasgow (bitbanged or not) is impractical at best? I'd like to make sure I've explored all the

12:36 <d1b2> options and this point before moving on towards a bread&butter ESP-Prog/FTDI board (for my particular use case, I'm not saying jtag_openocd applet is not good).

13:04 <d1b2> <Attie> @brainstorm - that comment from electronic_eel was re controlling pull up/down more dynamically I think, faster JTAG should be possible

13:06 <d1b2> <Attie> what resistor did you use on TDO? too high a value will limit your speed... try a scope again, and/or reducing the resistor's value... see if that resolves those warnings

13:29 <gruetzkopf> hi, i'm currently hitting libusb timeouts on every action i attempt with my glasgow (this is glasgow list) https://paste.ccc.ac/?5391c743b8f4f8e1#Jj2ZUfrrnEyX6T7jOhDAR1Wfp6H07x1XIjkNJ5z6Fks=

13:30 <gruetzkopf> this is a revC1 (out of Atties batch)

13:31 <d1b2> <Attie> ... I was about to ask if it's a known good board. should be if it's from me

13:31 <d1b2> <Attie> have you used it before?

13:31 <gruetzkopf> yup

13:31 <gruetzkopf> but nvm, seems to be a misbehaving usb hub

13:31 <d1b2> <Attie> ah, cool... I was about to suggest simple things like power cycle / direct to root hub

13:32 <d1b2> <Attie> so it's working now?

13:33 <gruetzkopf> works on the root hub

13:34 <d1b2> <Attie> nice

13:34 <gruetzkopf> but not two superspeed hubs down (hp dock - other devices like ethernet, mouse, usb2 stick work fine)

13:37 <d1b2> <Attie> hmm, that's frustrating

13:37 <d1b2> <Attie> I can't get into it now, but you've tried another cable, etc...?

13:38 <gruetzkopf> hm, doesn't fail reliably

13:38 <gruetzkopf> after replugging a bunch of times the port that was previously giving me issues works

13:42 <d1b2> <DX-MON> @brainstorm The speed you set on the Glasgow command line should be the one being respected as it becomes part of the synthesised bitstream for Glasgow's FPGA. 250kHz JTAG is yeah.. rather painful to work with because it's slow. Glad you got it mostly working. GDB will say no by default if you try and access memory areas it doesn't know about, however the command set mem inaccessible-by-default off will make it change its tune

13:48 <d1b2> <Attie> @gruetzkopf hmm... very frustrating. keep an eye on it and report back?

13:48 <gruetzkopf> yup, will also try different hubs

13:49 <d1b2> <Attie> I guess it could have been grubby contacts or something hand-wavey like that

13:49 <gruetzkopf> and also a fresh cable

20:27 <electronic_eel> @brainstorm: my comment was regarding implementing bus keepers or bus holders, like hardkrash mentioned, with the integrated pullups/pulldowns of Glasgow

20:29 <electronic_eel> i think that won't work, because bus keepers need to react fast to input changes, otherwise they will do more harm than good. and the glasgow pullups/pulldowns can't react fast enough because they are not directly connected to the fpga

20:54 <d1b2> <brainstorm> @Attie AFAIK I did not use any resistor, just the Glasgow pullup code on .claim_interface against the TDO pin... shall I add a physical resistor? Which value should be fine, 10k?

20:55 <d1b2> <brainstorm> @electronic_eel, gotcha, thanks, learning all this 😉