Closed mihaipora closed 8 years ago
This is funny .. If it's already in the readme it's probably my fault for not reading, if not then it's worth documenting the 'feature' : If I plug in the device and immediately run 'sudo lsusb -v', the device beeps and stops blinking and idrw_linux works properly.
If I plug in the device and I run idrw_linux before lsusb -v, then the device will not initialize properly even after running lsusb -v.
So: first thing to do after plugging in the device is 'sudo lsusb -v' and wait for the beep.
Anyway: good job and thanks for writing this.
It should be possible to generate the proper usb packets to initialize the device without the lsusb -v workaround. But I never found the time and motivation to do it. Glad it is useful for you.
I have the exact same output on lsusb -v so I will not repeat. The only difference is the USB3 driver (xhci_hcd) [70037.843043] usb 1-2: USB disconnect, device number 31 [70040.582870] usb 1-2: new low-speed USB device number 32 using xhci_hcd [70040.600433] usb 1-2: New USB device found, idVendor=ffff, idProduct=0035 [70040.600454] usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [70040.600467] usb 1-2: Product: USB Reader [70040.603281] usbhid 1-2:1.0: couldn't find an input interrupt endpoint
When running idrw_linux -r -v before lsusb there is an error as expectd: CMD_GET_SNR CRC_OK = 0x26 Outgoing packet, pkt_pl_unk = 0x08 STX OK 0xaa ETX OK 0xbb CMD_GET_SNR: 0x00 0x00
Control IN error -7
After lsusb -v the device still blinks, but it idrw_linux gives another error: CMD_GET_SNR CRC_OK = 0x26 Outgoing packet, pkt_pl_unk = 0x08 STX OK 0xaa ETX OK 0xbb CMD_GET_SNR: 0x00 0x00
CRC_OK = 0x80 Incoming packet, pkt_pl_unk = 0x00 STX OK 0x02 ETX OK 0x03 CMD_FAIL: 0x83 NOTAG
Any ideas ?