Running fpgajtag on Windows

[gardners]

Hello again, your chief causer of issues,

We have been porting fpgajtag to Windows (or rather, the version embedded into our MEGA65 debug tool).

We have managed to produce a binary that runs, can talk to the FTDI serial and JTAG interfaces, and can even do the JTAG device detection. However, when it comes to actually transferring a bitstream (which of course is our goal), it has trouble:

We get results like this:

X:\monitorload>monitor_load8.exe -l COM11 -b mega65r2test.bit
Getting started..
#0: fpgajtag: Digilent:Digilent USB Device:251633059648; bcd:700
Trying usb_index=0
USB device info: dev=000000001A7DAA60, idVendor=403, idProduct=6010, bcdDevice=700(0d1792)
USB bus=2, port_number=3
I'm on windows, and don't (yet) know how to work out the COMx: path.
In case it helps: bus=2, port=3
count 0/1 cortex -1 dcount 0 trail 0
STATUS 00401079 done 0 release_done 0 eos 10 startup_state 0
fpgajtag: Starting to send file
fpgajtag: Done sending file
[fpgajtag_main:1020] CONFIG_REG_BOOTSTS mismatch 0
[fpgajtag_main:1024] mismatch 88
fpgajtag: bypass first time 20
STATUS 00700019 done 0 release_done 0 eos 10 startup_state 4
fpgajtag: ERROR failed to run pciescanportal: No such file or directory
[T+3sec] Bitstream loaded

The FPGA board gets de-configured, but never completes the configuration process -- presumably because something (hopefully simple) has gone wrong in the setup prior to that point. We realise that this is not totally core for yourselves, but if in your USB hacking experience are able to offer any ideas on what might be going, this would be super helpful?

We have tried to do a bit of USB traffic capture using wireshark, but are happy to admit that we are clueless when it comes to understanding USB traffic.

The only things I have been able to see so far, is that Windows sends many smaller frames during the setup stage, compared with on Linux. Under Windows the bulk transfer of the bitstream then seems to die after sending just three packets.

Is it maybe some buffer getting full, perhaps

I have attached the two traces here, if they help provide any clues.

linux-working.pcap.gz
windows-notworking.pcap.gz

Thanks for any light you can help us shine on this,
Paul

[jankcorn]

Paul, I am still looking at the wireshark traces, but could you try a 'quick hack', just to see if it changes things? In fpgajtag.c, please change: #define MAX_SINGLE_USB_DATA 4046 to a shorter length (just for fun, how about 256) ? I am hoping that this will stay below the short USB mass transfer write sizes that you are seeing, just in case this is causing some weird side effect. I'll send more when I understand the wireshark traces better. Thanks! jca

…

On 5/20/20, gardners ***@***.***> wrote: Hello again, your chief causer of issues, We have been porting fpgajtag to Windows (or rather, the version embedded into our MEGA65 debug tool). We have managed to produce a binary that runs, can talk to the FTDI serial and JTAG interfaces, and can even do the JTAG device detection. However, when it comes to actually transferring a bitstream (which of course is our goal), it has trouble: We get results like this: ``` X:\monitorload>monitor_load8.exe -l COM11 -b mega65r2test.bit Getting started.. #0: fpgajtag: Digilent:Digilent USB Device:251633059648; bcd:700 Trying usb_index=0 USB device info: dev=000000001A7DAA60, idVendor=403, idProduct=6010, bcdDevice=700(0d1792) USB bus=2, port_number=3 I'm on windows, and don't (yet) know how to work out the COMx: path. In case it helps: bus=2, port=3 count 0/1 cortex -1 dcount 0 trail 0 STATUS 00401079 done 0 release_done 0 eos 10 startup_state 0 fpgajtag: Starting to send file fpgajtag: Done sending file [fpgajtag_main:1020] CONFIG_REG_BOOTSTS mismatch 0 [fpgajtag_main:1024] mismatch 88 fpgajtag: bypass first time 20 STATUS 00700019 done 0 release_done 0 eos 10 startup_state 4 fpgajtag: ERROR failed to run pciescanportal: No such file or directory [T+3sec] Bitstream loaded ``` The FPGA board gets de-configured, but never completes the configuration process -- presumably because something (hopefully simple) has gone wrong in the setup prior to that point. We realise that this is not totally core for yourselves, but if in your USB hacking experience are able to offer any ideas on what might be going, this would be super helpful? We have tried to do a bit of USB traffic capture using wireshark, but are happy to admit that we are clueless when it comes to understanding USB traffic. The only things I have been able to see so far, is that Windows sends many smaller frames during the setup stage, compared with on Linux. Under Windows the bulk transfer of the bitstream then seems to die after sending just three packets. Is it maybe some buffer getting full, perhaps I have attached the two traces here, if they help provide any clues. [linux-working.pcap.gz](https://github.com/cambridgehackers/fpgajtag/files/4660233/linux-working.pcap.gz) [windows-notworking.pcap.gz](https://github.com/cambridgehackers/fpgajtag/files/4660234/windows-notworking.pcap.gz) Thanks for any light you can help us shine on this, Paul -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #5

[gardners]

Thanks. I'll get the guys with the windows machine to test this when they get up.