USB errors with thumb drive in upper socket

[snhirsch]

trafficstars

The new USB support is nominally working, but I'm getting a lot of random 'usb_bulk_*' messages. Worse, I cannot transcribe them because my monitor is constantly displaying "Analog Input" at the upper left of the screen, obscuring most of the message. Something about the Pano video makes it go brain-dead. With Pano displayed, the entire monitor front panel is non-responsive. I cannot even turn it off until the Pano VGA is unplugged.

[skiphansen]

Is this a new issue with the latest changes or was it there in the last release as well? And is only when the thumb drive is in the upper socket? I assume you mean the one by the Ethernet port (which port 1 on the internal hub).

[snhirsch]

The last release didn't support the upper USB connector. This never occurred with the lower connector. The blasted on-screen input notice finally went away so I can transcribe the error:

usb_bulk_msg: submit_bulk_msg returned 0, status 32 usb_bulk_msg: returning -1, timeout 500 usb_stor_BBB_transport: usb_bulk_msg error status 32 usb_stor_read: Read ERROR, usb_read_10 returned -1 usb_bulk_msg: submit bulk_msg returned 0, status 128 usb_bulk_msg: returning -1, timeout 500 usb_stor_BBB_transport: usb_bulk_msg error status 128 usb_stor_read: Request sense returned 00 00 00

[snhirsch]

Update: With the latest firmware and bitstream I am also seeing this on the lower USB port. Sorry for the confusion!

[skiphansen]

Actually I didn't know it, but the upper USB port always worked with high speed devices, the bug only effected full speed and low speed devices. I'm assuming your thumb drive is high speed.

I must have left some debug prints enabled. I'll take a look at it tonight.

Thanks for the report!

[snhirsch]

Sure thing. I reverted the code back your previous level (keyboard fix) and cannot trigger any USB errors with the drive connected to the lower port.

I'm seeing an error from the second step in the 'prog_mcs' target, BTW, so perhaps I'm getting a proper flash. I'm using a gen-u-ine Xilinx USB pod under Linux using xc3sprog. It either complains about "no dongle" or spits out a long stream of USB error messages. Occasionally it will run as a separate step, but doesn't appear to do anything.

`hirsch@z87:/net/src/platforms/cpm/hardware/pano/pano_z80$ make xc3sprog -c xpc -v -I./fpga/xc3sprog/pano_g1.bit ./xilinx/pano_z80.mcs:W:0:MCS XC3SPROG (c) 2004-2011 xc3sprog project $Rev$ OS: Linux Free software: If you contribute nothing, expect nothing! Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?group_id=170565 Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop

Using built-in device list Using built-in cable list firmware version = 0x0012 (18) CPLD version = 0x0012 (18) JTAG chainpos: 0 Device IDCODE = 0x21c3a093 Desc: XC3S1600E Created from NCD file: top.ncd;UserID=0xFFFFFFFF Target device: 3s1600efg320 Created: 2019/08/11 16:06:27 Bitstream length: 5969696 bits done. Programming time 3195.4 ms JEDEC: 20 20 0x14 0x10 Found Numonyx M25P Device, Device ID 0x2014 256 bytes/page, 4096 pages = 1048576 bytes total Created from NCD file: Target device: Created:
Bitstream length: 6765472 bits Erasing sector 13/13....Writing data page 3303/ 3304 at flash page 3303.. Maximum erase time 688.5 ms, Max PP time 68847 us Verifying page 3304/ 3304 at flash page 3304 Verify: Success! USB Read Transactions: 15247 Write Transactions: 113491 Control Transaction 113500 xc3sprog -c xpc -v ./xilinx/work/pano_top.bit XC3SPROG (c) 2004-2011 xc3sprog project $Rev$ OS: Linux Free software: If you contribute nothing, expect nothing! Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?group_id=170565 Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop

Using built-in device list Using built-in cable list firmware version = 0x0012 (18) CPLD version = 0x0012 (18) usb_control_msg(0x28 12) error sending control message: Connection timed out Setting external mode: usage: xc3sprog -c cable [options] ... List of known cables is given with -c follow by no or invalid cablename filespec is filename:action:offset:style:length action on of 'w|W|v|r|R' w: erase whole area, write and verify W: Write with auto-sector erase and verify v: Verify device against filename r: Read from device,write to file, don't overwrite existing file R: Read from device and write to file, overwrite existing file Default action is 'w'

    Default offset is 0

    style: One of BIT|BIN|BPI|MCS|IHEX|HEX
    BIT: Xilinx .bit format
    BIN: Binary format
    BPI: Binary format not bit reversed
    MCS: Intel Hex File, LSB first
    IHEX: INTEL Hex format, MSB first (Use for Xilinx .mcs files!)
    HEX:  Hex dump format
    Default for FPGA|SPI|XCF is BIT
    Default for CPLD is JED
    Default for XMEGA is IHEX
    Default length is whole device

Makefile:20: recipe for target 'prog_msc' failed make: *** [prog_msc] Error 255 `

[skiphansen]

I'm not sure what's up with your xc3sprog error messages. It looks like you cable didn't like to be used twice back to back. According to xc3sprog the first operation that programmed the flash worked fine. The second operation just loads the bit file into the FPGA to reset the Pano failed. Try running the command "xc3sprog -c xpc -v ./xilinx/work/pano_top.bit" manually after the make fails and see if that works.

Weird, but as you noticed non-fatal.

I have had better luck with xc3sprog that iMPACT, but if installed ISE you might see if iMPACT works better for you. The basic operations in iMPACT work for me, but it crashed when I try to save/load some project files. I also STRONGLY prefer command line tools that GUI programs.

[skiphansen]

BTW I'm seeing similar "disk" errors as well. The last released enabled display of errors from the RISCV USB code. I don't get any errors on boot or when I run a few simple commands. However if I try lots of thing I eventually run into the errors. It's not very repeatable, it can start happening more or less right away or wait until I have done lots of things.

I don't think it has anything to do with which USB port is used,

[snhirsch]

Ah, ok. That second file is simply a convenience to avoid the need for power cycling? No big deal, then. I have an iMPACT install that has been dragged along through many Ubuntu updates. It used to work fine, but crashes now at the drop of a hat and is essentially unusable. I'll stick with command line tools.

[snhirsch]

Sorry, missed your reply about disk errors. That's my observation as well. Simple tasks don't trigger it, but when I run a 'make' on a large Turbo Modula-2 project it's triggered dozens of times. Eventually things die with unrecoverable disk errors. So, not just cosmetic. I could not reproduce this with the earlier bitstream and firmware.

[skiphansen]

Boy that was not I wanted to hear, so a regression then!

I did merge one change from my earlier USB stack attempt (which at least worked on the first port) which I hoped would fix the port 1 issue, it didn't. I kept that change anyway, I'll revert it and make a new release.

The actual port 1 fix was very simple and only effected the reading the device descriptor during device enumeration. It's hard to imagine it would cause new issues.

Of course I also made tons of changes to the logging while I was debugging which could also be an issue.

BTW: you are right failing operation is just a convenience. And your experience matches mine with iMPACT.