00:52 <_whitenotifier-4> [glasgow] whitequark created branch update-lockfile - https://github.com/GlasgowEmbedded/glasgow

00:52 <_whitenotifier-4> [glasgow] whitequark opened pull request #897: Update `pdm.min.lock` - https://github.com/GlasgowEmbedded/glasgow/pull/897

01:13 <_whitenotifier-4> [glasgow] whitequark synchronize pull request #897: Update `pdm.min.lock` - https://github.com/GlasgowEmbedded/glasgow/pull/897

01:18 <_whitenotifier-4> [glasgow] whitequark synchronize pull request #897: Update `pdm.min.lock` - https://github.com/GlasgowEmbedded/glasgow/pull/897

01:25 <_whitenotifier-4> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-897-97add00208d9f64b08126c6c3afd864ddb49ff2f - https://github.com/GlasgowEmbedded/glasgow

01:34 <_whitenotifier-4> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 2 commits to main [+0/-0/±3] https://github.com/GlasgowEmbedded/glasgow/compare/97add00208d9...0e36eecd1250

01:34 <_whitenotifier-4> [glasgow] whitequark closed pull request #897: Update `pdm.min.lock` - https://github.com/GlasgowEmbedded/glasgow/pull/897

01:34 <_whitenotifier-4> [glasgow] whitequark deleted branch update-lockfile - https://github.com/GlasgowEmbedded/glasgow

01:34 <_whitenotifier-4> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-897-97add00208d9f64b08126c6c3afd864ddb49ff2f - https://github.com/GlasgowEmbedded/glasgow

09:40 <mikecoatsdotcom[> Apologies for the wall of text... has anyone got any recommendations for debugging the Glasgow when you think you might have killed its USB somehow? I was running the `uart` applet when the `pty` disappeared and since then, despite reboots, the Glasgow doesn't show up any more. I can't see it under `lsusb` either. It doesn't seem to be the USB port or cable since running `udevadm monitor` shows other devices connecting just fine,

09:40 <mikecoatsdotcom[> just not the Glasgow. When it's plugged in, all the user leds come on, the PWR led comes on, and the 5v, 3v3 and 1v2 test points all read fine on the back. The ICE and ACT leds show a dim point of light in them and I can't tell if the FX2 led is off, or equally dim - it's outshone by PWR.

09:43 <whitequark[cis]> check the FX2 LED with a multimeter (you have one for the test points right?)

09:44 <whitequark[cis]> the other thing you could do is to plug it in while shorting the two pads labelled REC near the FX2 memory

09:44 <whitequark[cis]> these would be the first two basic steps in your case

09:44 <whitequark[cis]> also, did you have the firmware flashed?

09:58 <mikecoatsdotcom[> FX2 LED is glowing very dim and reads 2.35v. I've not flashed the firmware, I saw the message so it was on my list of todos but not yet. Shorting the FX2MEM & RECOVER doesn't seem to make any difference.

10:00 <whitequark[cis]> ok, so without the firmware it wouldn't be lighting any LEDs necessarily

10:00 <whitequark[cis]> can you take a photo of what you shorted? you need to connect those pads and then plug the device in, it should enumerate

10:14 <mikecoatsdotcom[> So, I found my pointiest pair of tweezers and shorted the pins again and I now get lots of messages about /devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-1/1-1:1.0 when I plug whilst shorted.

10:18 <mikecoatsdotcom[> lsusb now tells me Bus 001 Device 012: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit too.

10:27 <mikecoatsdotcom[> I managed to follow the steps in https://glasgow-embedded.org/latest/build.html and `glasgow factory --rev C3 --using-modified-design-files=no` and we're back in business. `lsusb` is returning `Bus 001 Device 015: ID 20b7:9db1 Qi Hardware Glasgow Debug Tool` again and `glasgow run selftest leds` is flashing away happily! Thanks so much for your help!

10:29 <whitequark[cis]> perfect

10:29 <whitequark[cis]> it's designed to be unbrickable

10:30 <whitequark[cis]> i have no idea how you managed to have the EEPROM wiped though

10:30 <whitequark[cis]> had I thought of it earlier I'd ask you for an EEPROM dump

10:35 <mikecoatsdotcom[> Yeah, genuinely no idea how that happened!

10:38 <whitequark[cis]> it's so puzzling

10:44 <mikecoatsdotcom[> I’ll try out what I was doing earlier and see if I can get a reproducible condition. No promises though!

17:49 <duskwuff[m]> I've had another FX2 based device lose its configuration with unstable power (tried powering it from a USB battery bank) - I haven't tried to replicate it but I imagine the EEPROM misinterpreted the FX2's read request as a write

18:11 <esden[m]> Just as a sidenote... the way you called factory erased the serial number from the flash. So it will now not match the sticker on the back of the board.

18:12 <esden[m]> I think it put a new serial number in the flash if you force factory prog. It is not a functional issue, but don't be surprised that the sticker does not match your board any more. 🙂

18:20 <q3k[cis]> <whitequark[cis]> "i have no idea how you managed..." <- i mean, REQ_EEPROM is one bitflip away from REQ_FPGA_CFG :)