07:10 <s_frit> is it possible to get iceprog to write bitstreams generated by icecube2? it gets to "programming.." then "Write error (single byte, rc=0, expected 1).

07:13 <daveshah> Yes, I've never seen any problems doing that

07:14 <daveshah> Have you tried it with an icestorm bitstream to rule out other issues?

07:15 <s_frit> hmm no, because i haven't yet set up icestorm. are there some test bitstreams (e.g. one that flashes LED on upduino2) or can i somehow pack the .hex bitstream that comes with upduino2?

07:17 <s_frit> i tried using iceunpack on my icecube2 bitstreams, and the unpacked files seem to end with something like ".extra_bit 1 690 174". if i delete that line, repack, and use iceprog then the write succeeds but verification fails

07:18 <s_frit> perhaps i'm using the wrong bitstream files from icecube2? i'm using the ones with the .bin extension found in sbt/outputs/bitmap. Diamond writes them to the device ok

07:19 <daveshah> The extra_bit is very much needed, it's part of the global clock network

07:19 <daveshah> Try this bitstream

07:20 <daveshah> https://usercontent.irccloud-cdn.com/file/rT0Z3aDP/rgb.bin

07:23 <s_frit> thanks. i get the same error that i initially described

07:25 <daveshah> Seems like an issue with libusb or somewhere else in the usb stack then, unrelated to the bitstream

07:27 <s_frit> here's the full output. note that i get the same result with/without -s flag. https://pastebin.com/gtt1SzmT

07:31 <s_frit> the other thing i notice is that after running iceprog and it failing, if i run lsusb again, the device id of the ftdi device has incremented

07:31 <daveshah> That sounds crazy

07:31 <daveshah> Try a different USB cable and socket

07:34 <s_frit> already tried a different socket. looking for cable...

07:37 <s_frit> ok. i tried another cable. iceprog seemed to run for longer before erroring. so i dropped the -s flag, and tried it a bunch of times (it kept erroring) then it got through to verifying (and failed) but now the LED is on white. is that what the program is supposed to do?

07:38 <daveshah> It should be fading the LED using the HFOSC

07:38 <daveshah> If verifying is failing then that would explain it not working...

07:40 <s_frit> ok. yeah it is working now

07:40 <s_frit> i mean, i have your example working

07:40 <s_frit> still getting failures while programming intermittently

07:41 <s_frit> i think part of the problem was that i'd left VCCIO floating. so i've tied that to ground now. but i'm still getting intermittent failures

07:42 <s_frit> erm VCCIO_2 that is

07:45 <s_frit> my icecube2 bitstreams also seem to be working (when i can get them to write without error)

07:45 <daveshah> This is nothing to do with the FPGA though - the first error is between the PC and the FTDI, the second might also involve the flash

07:45 <daveshah> So I doubt VccIO would make a significant difference

07:45 <s_frit> hmm ok

07:46 <s_frit> maybe there is a dodgy connection on the board. i'll take a look when i get to the lab

07:46 <daveshah> Unless there are any FTDI or flash pins on that bank?

07:46 <daveshah> Then VccIO should be at 3.3V otherwise those signals will be grounded through the ESD diode when VccIO is grounded

07:46 <s_frit> no. the FTDI/Flash stuff is all on the bank that's fixed to 3v3 i'm pretty sure

07:48 <daveshah> Yeah, VccIO2 won't matter then

07:48 <s_frit> could be i messed something else up with my greenwire job. i don't have any magnification here though, so it will have to wait. thanks for your help, this at least gets me to the next step

07:48 <s_frit> i'll try with a different machine later too

07:48 <s_frit> microusb cables are untrustworthy hobitses

07:50 <s_frit> the other thing is, i've had no problem programming this board with Diamond on a different machine

07:51 <s_frit> the only electrical variable there is a different cable

07:53 <daveshah> Could also just be small differences in the commands and timings that the two tools use

08:03 <s_frit> would that account for the device connecting from the bus?

08:04 <s_frit> *disconnecting

08:04 <s_frit> i'll try another machine and another cable in a couple of hours and report back