search

im-tomu / fomu-workshop

Support files for participating in a Fomu workshop
https://workshop.fomu.im
Apache License 2.0
162 stars 64 forks source link

wishbone-tool shows occasional BridgeError #49

Closed ret closed 5 years ago

ret commented 5 years ago

In the litex/workshop.py and litex/workshop_rgb.py examples, I often have to retry reads and writes via the wishbone-tool to work around BridgeError(USBError(Pipe)). This is happening on box Linux and OSX for me.

Have others experienced similar reliability challanges?

$ dfu-util -D build/gateware/top.dfu 
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Match vendor ID from file: 5bf0
Match product ID from file: 1209
Opening DFU capable USB device...
ID 1209:5bf0
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0101
Device returned transfer size 1024
Copying data from PC to DFU device
Download    [=========================] 100%       104090 bytes
Download done.
state(7) = dfuMANIFEST, status(0) = No error condition is present
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!

$ wishbone-tool 0x10000000
INFO [wishbone_tool::usb_bridge] opened USB device device 008 on bus 020
ERROR [wishbone_tool] server error: BridgeError(USBError(Pipe))
INFO [wishbone_tool::usb_bridge] waiting for target device
^C

$ wishbone-tool 0x10000000
INFO [wishbone_tool::usb_bridge] opened USB device device 008 on bus 020
Value at 10000000: 4019c91a

$ wishbone-tool 0x10000000 1
INFO [wishbone_tool::usb_bridge] opened USB device device 008 on bus 020
ERROR [wishbone_tool] server error: BridgeError(USBError(Pipe))
INFO [wishbone_tool::usb_bridge] waiting for target device
^C

$ wishbone-tool 0x10000000 1
INFO [wishbone_tool::usb_bridge] opened USB device device 008 on bus 020
ERROR [wishbone_tool] server error: BridgeError(USBError(Pipe))
INFO [wishbone_tool::usb_bridge] waiting for target device
^C

$ wishbone-tool 0x10000000 1
INFO [wishbone_tool::usb_bridge] opened USB device device 008 on bus 020
ERROR [wishbone_tool] server error: BridgeError(USBError(Pipe))
INFO [wishbone_tool::usb_bridge] waiting for target device
^C

$ wishbone-tool 0x10000000 1
INFO [wishbone_tool::usb_bridge] opened USB device device 008 on bus 020
ERROR [wishbone_tool] server error: BridgeError(USBError(Pipe))
INFO [wishbone_tool::usb_bridge] waiting for target device
^C

$ wishbone-tool 0x10000000 1
INFO [wishbone_tool::usb_bridge] opened USB device device 008 on bus 020

$ wishbone-tool 0x10000000 
INFO [wishbone_tool::usb_bridge] opened USB device device 008 on bus 020
ERROR [wishbone_tool] server error: BridgeError(USBError(Io))
INFO [wishbone_tool::usb_bridge] waiting for target device
^C

$ wishbone-tool 0x10000000 
INFO [wishbone_tool::usb_bridge] opened USB device device 008 on bus 020
Value at 10000000: 00000001
xobs commented 5 years ago

I spent all day yesterday working on debugging the problem.  I rewrote the entirety of dummyusb.  It's ~3% smaller now (and uses 200 fewer LUTs).

Naturally the problem was somewhere else.

The problem was due to skew between the 48 MHz and 12 MHz clock domains.  We used to use a Clock Resource Generator (CRG) from the litex_boards repository, but that got removed.  Rather than fixing it upstream, I added a CRG to workshop.py and workshop_rgb.py. We'll get that change pushed upstream, but for now we'll keep the local copy of the CRG within the workshop files.

If you update litex-workshop it should work now.  If you then do a git submodule sync, you should get the new USB core that's 200 LCs smaller.

ret commented 5 years ago

Wow! Thanks a ton, Sean! Will rerun my experiment and close this issue later today.

ret commented 5 years ago

Confirming https://github.com/im-tomu/fomu-workshop/commit/d8c9b7281e42d97c40d8f76a232e7f43b52ec04b and https://github.com/im-tomu/fomu-workshop/commit/b85466f525ee989c5ea04e15c77cc492f3b702df fixed the issue.