mpsse_write: fail to write with error -1 (usb bulk write failed)

[pangdahaiNo1]

The problem is described below,I hope someone could solve it.

sudo ./openFPGALoader -c digilent_hs2 --freq 15000000 --index-chain 1 -m --bitstream ./top.bit 
write to ram
Jtag frequency : requested 15.00MHz  -> real 15.00MHz 
Open file DONE
Parse file DONE
load program
mpsse_write: fail to write with error -1 (usb bulk write failed)
mpsse_write: fail to write with error -1 (usb bulk write failed)

the board I used is zbaz4203,which is not common more info

$uname -a
Linux pangdahai-B360-GAMER 5.15.0-71-generic #78~20.04.1-Ubuntu SMP Wed Apr 19 11:26:48 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
$./openFPGALoader -V
openFPGALoader v0.10.0
$sudo dmesg | grep -i ftdi
[  850.055963] usb 1-5.4: FTDI USB Serial Device converter now attached to ttyUSB0
[  851.065190] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[  851.065200] ftdi_sio 1-5.4:1.0: device disconnected
[ 1856.903820] ftdi_sio 1-5.4:1.0: FTDI USB Serial Device converter detected
[ 1856.904289] usb 1-5.4: FTDI USB Serial Device converter now attached to ttyUSB0
$getent group dialout
dialout:x:20:
$sudo ./openFPGALoader -c digilent_hs2 --freq 15000000   --detect
Jtag frequency : requested 15.00MHz  -> real 15.00MHz 
index 0:
    idcode   0x4ba00477
    type     ARM cortex A9
    irlength 4
index 1:
    idcode 0x3722093
    manufacturer xilinx
    family zynq
    model  xc7z010
    irlength 6

[trabucayre]

Could you provides more informations about your board: I'm unable to find anything about this one. You use a real digilent_hs2? You use sudo so it's not an issue related to access right. Error is more at the libftdi level. Last time I have seen this error it was when using some ch552 with a firmware implementing FTDI MPSSE instructions.

[zmij]

Hi @trabucayre

I'm having the same problem with tangnano4

$ openFPGALoader -b tangnano4k -f impl/pnr/key_blink.fs 
write to flash
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
Parse file Parse impl/pnr/key_blink.fs: 
Done
DONE
Jtag frequency : requested 2.50MHz   -> real 2.00MHz  
erase SRAM Done
erase Flash Done
write Flash: [============================================      ] 86.32%mpsse_write: fail to write with error -1 (usb bulk write failed)
mpsse_write: fail to write with error -1 (usb bulk write failed)
mpsse_store: fails to first flush -1 usb bulk write failed
mpsse_write: fail to write with error -1 (usb bulk write failed)
# errors continue until ctrl+C

After this the device disconnects and reconnects only after plugging it out and back in.

Additional info:

$ openFPGALoader -V
openFPGALoader v0.10.0

$ openFPGALoader --detect --verbose-level=2
No cable or board specified: using direct ft2232 interface
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
Raw IDCODE:
- 0 -> 0x0100981b
- 1 -> 0xffffffff
- 2 -> 0xffffffff
- 3 -> 0xffffffff
- 4 -> 0xffffffff
found 1 devices
index 0:
    idcode 0x100981b
    manufacturer Gowin
    family GW1NSR
    model  GW1NSR-4C
    irlength 8

[pangdahaiNo1]

I'm sorry I didn't reply in time. I'm sure I was using the real digilent_hs2 before. if you can't find information about the ebaz4203, you can also look up the zbaz4205, the two boards are very similar. I found some info on github: https://github.com/xjtuecho/EBAZ4205. I don't think it's necessarily the board though, since this board doesn't have a matching jtag cable, I used a dupont line and a jtag downloader to connect it, so it may have poor contact. I recently used the pynq-z2 with a faulty cable connection and found that it produces the same error.

[trabucayre]

@pangdahaiNo1 Yes, sometime a bad cable or dupont cable may produces wrong behavior. Could you try with something more robust to validate/unvalidate this assumption? @zmij could you provides dmesg output. usb<->jtag interface is known to have issue in some situation (especially with RPI).

[zmij]

Hello @trabucayre, this was a usb hub problem. I was connecting the board to my MacBook via a usb hub, after I connected the board directly to MacBook's type-c port, the problem was gone.