Open jeffpc opened 1 year ago
I just tried on a Linux host and it errors out as well. The errors seem to hint at the same kind of problem - the device isn't responding like it should during init.
[3113882.808075] usb 2-1: new full-speed USB device number 17 using xhci_hcd
[3113882.808260] usb 2-1: Device not responding to setup address.
[3113883.016256] usb 2-1: Device not responding to setup address.
[3113883.224030] usb 2-1: device not accepting address 17, error -71
[3113883.352016] usb 2-1: new full-speed USB device number 18 using xhci_hcd
[3113883.352201] usb 2-1: Device not responding to setup address.
[3113883.560265] usb 2-1: Device not responding to setup address.
[3113883.768024] usb 2-1: device not accepting address 18, error -71
[3113883.768203] usb usb2-port1: unable to enumerate USB device
[3113885.192058] usb 2-1: new full-speed USB device number 19 using xhci_hcd
[3113885.320096] usb 2-1: device descriptor read/64, error -71
[3113885.556095] usb 2-1: device descriptor read/64, error -71
[3113885.791989] usb 2-1: new full-speed USB device number 20 using xhci_hcd
[3113885.924091] usb 2-1: device descriptor read/64, error -71
[3113886.160090] usb 2-1: device descriptor read/64, error -71
[3113886.268132] usb usb2-port1: attempt power cycle
I am observing the same behaviour on a custom iCE40 development board. I have programmed the board using tinyprog
and a small Teensy/Arduino implementation of the bootloader. When accessing the flash through the programmer, the board correctly reports the metadata and is able to write and validate the bootloader image as well.
After disconnecting the programmer and plugging in the USB to the FPGA board, the board demonstrates the expected behaviour; i.e. the on-board LED slowly blinks and the USB pull-up is asserted. On the host PC side I observed the same log messages as above. Using an oscilloscope to measure the D+/D- lines, I was able to observe that the bootloader does not accept the address assigned to it. This is further evidenced by the fact that the test for USB address setting fails.
In brief, there is a regression that results in the bootloader being unusable as of commit #97f6353540bf7c0d27f5612f202b48f41da75299.
To add, I am unable to verify what the last usable commit is.
Latest commit to pass tests that I found is a625448. This commit does not appear to work on hardware, however.
FWIW, I received as second TinyFPGA-BX from Mouser and it displays the same exact issue.
I just tried on a Linux host and it errors out as well. The errors seem to hint at the same kind of problem - the device isn't responding like it should during init.
[3113882.808075] usb 2-1: new full-speed USB device number 17 using xhci_hcd [3113882.808260] usb 2-1: Device not responding to setup address. [3113883.016256] usb 2-1: Device not responding to setup address. [3113883.224030] usb 2-1: device not accepting address 17, error -71 [3113883.352016] usb 2-1: new full-speed USB device number 18 using xhci_hcd [3113883.352201] usb 2-1: Device not responding to setup address. [3113883.560265] usb 2-1: Device not responding to setup address. [3113883.768024] usb 2-1: device not accepting address 18, error -71 [3113883.768203] usb usb2-port1: unable to enumerate USB device [3113885.192058] usb 2-1: new full-speed USB device number 19 using xhci_hcd [3113885.320096] usb 2-1: device descriptor read/64, error -71 [3113885.556095] usb 2-1: device descriptor read/64, error -71 [3113885.791989] usb 2-1: new full-speed USB device number 20 using xhci_hcd [3113885.924091] usb 2-1: device descriptor read/64, error -71 [3113886.160090] usb 2-1: device descriptor read/64, error -71 [3113886.268132] usb usb2-port1: attempt power cycle
I ran into the same issue. The work-around was to put a hub between the PC USB port and the TinyFPGA-BX.
(Hopefully this is the right place to file this.)
I just got a TinyFPGA-BX, put the thru-hole headers on it, and connected it to my FreeBSD 13.2 desktop. The power LED turns on, the boot LED starts blinking, but the FreeBSD kernel doesn't like what it sees (see syslog copy & paste below). From my very limited knowledge of USB, it looks like mid-way through USB device setup, the device (IOW, the bootloader on the BX) refuses to or times out during the "set address" portion of initialization. The host or device disconnects and reconnects, and then the whole thing happens again.
Because the device isn't fully initialized, the kernel doesn't let userspace applications use it.
Probing the SPI pins during power on, I see the serial clock and data moving between the SPI flash and FPGA.